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góta a koponyánk körül 


Semmi sem a sajátod azon a néhán 
köbcentiméteren kívül, ami a fejedben van. 


(George Orwell) 


Egy laikus számára úgy tűnhet, hogy egy informatikus szakma legfontosabb kelléke a pingvines-, vagy 
ablakos kávésbögre, és egy hátizsáknyi telepítő CD. Ez nem így van. Az informatikus legfontosabb 
munkaeszközét a nyakán hordozza, és gondos gazdaként karban kell tartania azt. Erről lesz szó rövid 


kis sétánk alatt. Tartsanak velem! 


A cikket gondolatébresztőnek szánom. Gondolatébresztőnek 
és gondolkozásra serkentőnek, hiszen a téma — választott hi- 
vatásánál fogva — közvetlenül érint minden szakmabélit. Én 
magam talán akkor gondolkoztam rajta először, mikor egy be- 
szélgetés során azt hallottam, hogy ,jó informatikus, ő min- 
denhez ért". Hmm... 

Hirtelen megjelent lelki szemeim előtt hősünk ,IT" feliratos 
szupermen jelmezében, mint az informatika minden jelenleg 
ismert ágának feketeöves nagymestere. Ha valaki a leírás 
alapján magára ismer, kérem, hogy jelentkezzen (jutalma 
egy csattogószárnyú fapillangó). 


Hová tűnt szupermen? 


Létezik a valóságban szupermenünk? Egyáltalán létezhet? 
Nehéz ügy, meglehetősen kicsi a valószínűsége. Hogy miért 
állítom ezt? Mert az informatika tudománya elérte a bonyo- 
lultságot, vagyis azt a komplexitáshatárt, hogy szaktudomá- 
nyokra szakadjon. (Az egyik ilyen szaktudomány, vagyis 
diszciplína ismereteit feldolgozó lapot tart kezében a kedves 
olvasó.) 

A jelenség nem példa nélküli, gondoljunk csak a fizikára, 
matematikára, közgazdaságtanra, vagy az orvostudományra. 
A folyamatos kutatás és fejlesztés, az ismeretek és a tudásbá- 
zis szakadatlan bővülése magában hordozza az alapdiszcip- 
lína szakterületekre szakadásának szükségességét. Könnyebb 
ezt megérteni, ha az elejétől kezdve figyelemmel kísérjük a 
történetet. 

Mikor egy ifjú titán ismerkedni kezd egy tudománnyal, egy 
nagy hegy megmászásába fog bele. A hegy maga a megismer- 
ni kívánt diszciplína, melynek alkotóelemei a kognitív sémák, 
a gondolkodás aktív alakuló mintái. Ezek a megismerési sé- 
mák önálló jelentéssel bírnak és önmagukban is értelmesek. 
Külön-külön azonban nem sok hasznukat vesszük, bonyolult 
és szövevényes kapcsolatrendszerük alkotja az elsajátítani kí- 
vánt szaktudományt. 


Stabil alapra szükség van! 


Sémák nélkül nem megy. Téglák nélkül nem épül fel a ház, ha 
nincsenek meg a sziklák, soha nem érünk fel a csúcsra. Mert 
nem lesz hová. 

Bizony az alapozás fáradságos és időigényes művelet, de 
nem kerülhető meg. Az adott diszciplína alapjait képző sé- 
mák megismerésére szükség van, mivel a bonyolultabb sé- 
mák egyszerű sémákra épülnek. Sőt, a sémák szövevényes 
kapcsolatrendszere miatt nem elegendő csupán az egyes sé- 
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mák bemagolása, a közöttük lévő összefüggések megismeré- 
sére is törekedni kell. Csak így ,állhat össze a kép". De ne 
szaladjunk előre. 


Az amatőrtől a Jedi lovagig 


Vajon mi a különbség a nagymester és a botladozó amatőr kö- 
zött? Erre a kérdésre leggyakrabban azt a választ kapom, hogy 
va profi többet tud". Ennyi lenne? Magoljunk és tejcsokoládé 

fog potyogni az égből? Vagy máshogy 


Ez tudja, amit tud? Vagy más módon 


gondolkodik? Mitől? Nehéz rövid és 
Aki tanul, de nem gon frappáns válaszokat megfogalmazni 
ezekre a kérdésekre. Nem is lehet ez 
dolkodik, elveszett a célom. Azonban sok dolog a helyé- 
re kerülhet, ha figyelmesen tanulmá- 
nyozzuk a táblázatot (Mérő László, 
2001) a következő oldalon. 
Az egyes szinteket az elsajátított kog- 
nitív sémák mennyisége határozza 
meg. Átlagos általános műveltséget 
feltételezve elmondható, hogy a leg- 
Konfucius több diszciplínában a kezdő, vagy 
haladó szintet mindenki eléri. Olyan 
területek sémáival is rendelkezünk, 
amelyek nem kapcsolódnak szorosan mindennapi mun- 
kánkhoz. Bár nem vagyunk orvosok, tudjuk mi a vérvétel, a 
műtét és a foghúzás. Legtöbben közülünk nem képzett köz- 
gazdászok, de ismerik a tőzsde, a részvény, a kamat fogalmát. 
Természetesen mivel nem vagyunk a terület szakértői, ezek a 
sémáink nem annyira komplexek és árnyaltak, mint amilye- 
nekkel a diszciplína felkent nagymesterei rendelkeznek. Ez 
nem is meglepő, ha figyelembe vesszük a tanuláshoz, a 
megismeréshez és az éréshez szükséges 5-10 évet. 
Akkor hogyan is volt ez a szupermen dolog? Miért nehéz min- 
denhez érteni? Egy nagymester néhány 10 000, az adott terü- 
lethez tartozó kognitív sémával rendelkezik. Miért nem töb- 
bel? A vizsgálatok szerint szakterülettől függetlenül, minden 
diszciplína esetében megállt ezen a szinten a sémák számá- 
nak növekedése. Természetesen ezzel nem. fejeződött be az 
egyén fejlődése, hiszen a fejében lévő sémák dinamikus, ál- 
landóan változó rendszert alkotnak. A sémái egyre árnyaltab- 
bak és kifinomultabbak lesznek. De a számuk nagyságrendi- 
leg már nem változik. Ennek okát nem az emberi memória 
korlátozott kapacitásában kell keresni. A téma szakértői sze- 
Folytatás a 4. oldalon. 


ember. Aki gondolko- 
dik, de nem tanul, 


nagy veszélyben van. 
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A DRLP rejtett szépségei — III. 


Előző alkalommal telepítettünk és címtartománnyal szereltünk fel egy DHCP- 
kiszolgálót, majd elkalandoztunk a DNS- és DHCP-integráció területére. 
Most még egy rövid időre visszatérünk a scope-okhoz, és alaposan 
szemügyre vesszük, milyen részei vannak, és milyen lehetőségekkel ren- 
delkezünk a címtartományok kiterjesztésére. 





zza Internet Information Services 5.0, III. rész 
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Az SMTP rendszerszolgáltatás a Windows 2000-hez képest egyetlen do- 
log (az LDAP útválasztás) kivételével nem tartalmaz igazán sok újdonsá- 
got. A következő leírás így a Windows 2000 üzemeltetőinek is jó szolgá- 
latot tehet. 
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A Windows System Resource keres MRM Sage OBA, Etán Elton 
Manager fesse [De] [eze] 








ISZESSSE ETT öt SSEL E SES NT NET SET TOK TÉL 
Vége az erőforrásokért folyó R8 Ig s 9 
versengésnek! — mmm KNNKNHETT EEEN KETIZAI 
A Windows System Resource Manager a folyamatok priori- d SPUIdő felhasználás t 


tását dinamikusan változtató algoritmus segítségével képes Working set: 20MB Working set: 20MB 
éz. jők 414c4 éz alia Committed mem: BOMB Committed mem:BOMB 
arra, hogy azok erőforrás-felhasználását az előre beállított 
határértékek alatt tartsa, így biztosítva az erőforrások opti- 
mális kihasználtságát. 


Memóriakiosztás 





IA Server 2000, Featurg Pack 1! 


Új téglák a (tűz)falban 

A nemrégiben megjelent ISA Server 2000 Feature Pack 1 segítségével tűz- 
falunk funkciói kiteljesednek (kiterjedt SMTP-filter, URLScan 2.5 stb.), né- 
hány mindennapos feladat megoldása sokkal egyszerűbbé válik (például 
az OWA kiszolgálóik publikálása). És ez még nem minden! 








ISA kiszolgáló 
4 Feature Pack1 


Web-alapú tárnadások 





Biztonságos aláírás kezelő alkalmazás készítése III. mm 


Avagy a bürokrácia diszkrét bája 


Az ember minden épeszű mértéken áthágva képes elbonyolítani tulajdon életét. Ez külö- 

nösen igaz társadalmi méretekben, pláne ha az adminisztráció oldaláról közelítjük meg a 

jelenséget. Az elektronikus dokumentumkezelés és aláírás sajnos ezen mit sem javít: csak a hagyo- 
mányos papír alapú adminisztrációt képzi le elektronikus formára. A kommunikáció felgyorsulhat és egyszerűsödhet, de a fo- 
Ilyamatok alapvetően nem változnak. Mivel az aláírás (akár a hagyományos, akár az elektronikus) egy jogi szempontból is ér- 
vényes kötelezettségvállalást fejezhet ki, duplán igaz rá minden bürokratikus szabály. Nem az elektronikus aláírás bonyolult, 
hanem az élet, aminek próbál megfelelni. 


ÉL 


Elliptikus görbe kriptorendszerek I. rész 


Elliptic Curve Cryptography - elméleti háttér 


Egy jó ideje egyre több helyen találkozhatunk az ECC betűhármassal, mint egy 
kriptorendszer megjelölésével. Egyre több előnyéről hallunk: az RSA-nál rövidebb 
kulcsokkal érhető el ugyanakkora biztonság, gyorsabb a működése, kisebb a me- 
móriaigénye. Mindezek a SmartCard technológia biztonsági eszközeit is az ECC fe- 
lé fordítják. De mi is ez? Elliptic Curve Cryptosystem, bár gondolom ettől most so- 
kan nem lettek okosabbak, nekik (is) szól az a kétrészes cikksorozat, melynek első 
része következik. 
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sszázákalzén SPAM, anti-SPAI 


avagy Sajnos Pont A Mailboxomban 
gyülekező nemkívánatos adathalmaz 

Napjaink egyik legkellemetlenebb problémájával foglalkozom ebben 
a cikkben, mégpedig a nem kért, de mégis tömegével kapott e-mail 
üzenetekkel, amelyek eláraszthatnak mindenkit, aki akár csak egyszer 
is küldött valaha egy e-mailt bárhova a saját hálózatán kívülre. 
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Aki SOL Serverrel foglakozik, akár fejlesztőként, akár rendszergazdaként idő- 7. Stan SOL Server if itis stopped 
ről-időre találkozhat , rejtélyes" esetekkel. Amikor valami okból nem úgy fut ű § 
z 4 di 21: a 4 jonneot using 
egy alkalmazásunk, ahogy mi elvárjuk, és sehol nem találjuk a hiba okát. €7. vindowme aáhartsátlán 


Ilyenkor érdemes az SOL Profilerhez fordulnunk. Ez az eszköz az SOL Server C SOL Server authentication 
részeként sokszor segítheti munkánkat. 


33. oldal 





Cancel Help 





Objektum Örientált Alkalmazásfejlesztés I. 
OOP, OOA, UML, DP, RUP, ER, ORM, ... Sokáig folytathatnám még a 
HBR-eket O), amelyek a szoftvertervezés és -fejlesztés során felmerül- 
EZÉ nek, és amelyek tengerében nagyon könnyen el lehet veszni. Az útkere- 
sés során látni fogjuk, hogy nem elég, ha az ember ismeri a rövidítések 

jelentését, a lexikális tudás mellett rengeteg egyéb képességre kell szert 
tennünk. 


EÉEI ESZ 37. oldal 
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Folytatás a 4. oldalról. 

rint a magyarázat erre egyfajta komplexitási szint 
elérése lehet. Amennyiben egy tudomány eléri ezt a 
szintet, szakterületekre szakad, melyek kinevelik sa- 
ját szakértőiket és nagymestereiket. Magától értető- 
dően lesznek közös kognitív sémák, hiszen osztanak, szoroz- 
nak a matematikusok és a fizikusok is, és a protokoll, merev- 
lemez, kernel, DNS fogalma ismerős minden informatikával 
foglalkozó számára. A sémák újra felhasználhatóak, ezért iga- 
zodik el könnyebben egy szakterület ismerője egy , rokon" te- 
rületen. 


Mester, mit javasolsz? 


A mindennapi munkavégzés során számos megoldandó prob- 
lémával találkozunk. A rutinfeladatokat nem tekintem problé- 
mának, mert ezek jól ismert, gyakran jelentkező feladatok. Ki- 
dolgozott és begyakorolt forgatókönyvek alapján nem jelent 
szellemi teljesítményt az elvégzésük. Probléma az, amire 
nincs kidolgozott, kész megoldásunk. 

Az egyes tudásszinteken jelentősen eltér a megoldandó prob- 
lémára adott megoldási javaslatok száma. Kezdőszinten na- 
gyon kevés a sémák száma, sokszor a probléma azonosításá- 
hoz sem elegendő, így nincs értékelhető megoldás. A haladó 


1993 Windows NT 3.1 
1994 Windows NT 3.5 
1995 Windows NT 3.51 
1996 Windows NT4 
2000 Windows 2000 
2003 Windows 2003 


Röpke 10 év, 6 szervertermék, 4 generáció. És a táblázatban 
csak a szervertermékek szerepelnek, nem szóltam a klienster- 
mékekről, alkalmazásokról, fejlesztőeszközökről. Évente biz- 
tosan megjelenik egy új, meghatározó termék újdonságok (új 
sémák) tömegét zúdítva a szakmára. Mire gondolok? Íme: 
AD/AM, VDS, VSS, CMAK, PPPoE, PEAP, RSoP, SUS, EMS. 
Mindegyik ismerős? Egyiket sem kell magyarázni? És hol vol- 
tak ezek 1-2 éve? 

Bizony ez nem az a ,karosszékben hátradőlős" szakma. Mit 
jelent ez a szakemberek számára? Folyamatos tanulást. 


Hol a határ? 


Igen, folyamatosan kell tanulni. Figyelem! A folyamatos tanu- 
lás nem csupán ahhoz szükséges, hogy felfelé másszunk a 
képzeletbeli hegyen, hanem ahhoz is, hogy ne csússzunk le- 
felé! 





Kognitív sémák mennyisége néhány 10 néhány 100 
Kognitív sémák minősége bonyolult, hétköznapi egyszerű, adekvát, 
inadekvát nem kielégítő 


"logikus, a hétköznapi 
. logika szerint 
— szakszerűtlen, hétköznapi 


Problémamegoldás módja 1 


Szakmai kommunikáció 


logikátlan, mert kevert 


görcsös, hullámzó 


néhány 1000 
bonyolult, adekvát, 
szakszerű 


néhány 10 000 
komplex, analógiák 








logikus, analitikus, 
a szakmai logika szerint 
szakmailag korrekt, 


I képi, szintetikus, gyakran 
transzlogikus 
mélyen intuitív, 


minősége intuícióra alapoz színvonalú formális, tárgyszerű informális, áttekintő 
Szakmai nyelve nincs nehézkes, , ideges" szabályszerű, kifejező sanyanyelvi", képszerű 
Gondolkodási stílus intuitív kevert, ezért gyakran racionális intuitív 


logikátlan 
Tudatosság szintje még nem tudja, 


mit nem tud 


Érésideje § 
Mi kell hozzá érdeklődés, tanulás 


néhány év 


tudja, mit nem tud még 


folyamatos tanulás 


tudja, mit honnan tud tudja, mi a helyénvaló, 


de nem tudja honnan 


kb. 5 év minimum 10 év 
képzettség, iskolai tehetség 
végzettség 


szint a legveszélyesebb, mert már ismer szakkifejezéseket, és 
a maga logikátlan, kevert módján minden, a témával kapcso- 
latos ismeretét megoldásnak véli. Rengeteg megoldást javasol, 
ezek túlnyomó része használhatatlan. A szakértő már rendel- 
kezik azzal a tudással, ami könyvekből megtanulható. Felis- 
meri a kapcsolatokat, és szakmai logika szerint racionálisan 
keresi a lehetséges megoldásokat. A haladónál lényegesen ke- 
vesebb, de még mindig ,sok" megoldást javasol, mely megol- 
dások szakmai ismeretekkel alátámasztottak és többnyire 
megfelelő választ adnak a vizsgált problémára. A ,nagymes- 
ter" gondolkodása mélyen intuitív, probléma megoldási mód- 
ja képi, szintetikus, gyakran transzlogikus. Csupán néhány 
megoldást javasol, azonban ezek között gyakran található for- 
radalmian új, más megközelítésű, ,nagy ötlet", ami még soha, 
senkinek nem jutott eszébe, mégis tökéletes megoldása a fel- 
vetett problémának. 


Egyetlen dolog állandó: a változás 


Bár az informatika ember alkotta világ — így elméletileg telje- 
sen megismerhető — szupermenünk dolgát tovább nehezíti a 
fejlődés üteme. Nemrég egy Microsoft prezentációban láttam 
a következő adatokat: 


Rendben, tanulunk, fejlődünk, de meddig? Jön egy fal? Be- 
mondják, hogy , végállomás, kérjük, szálljanak le"? Vannak az 
emberi megismerésnek és a technikai fejlődésnek határai? 
Nem fogok jövendölésekbe bocsátkozni, mert ebbe nagy em- 
berek is belesültek (640 kByte memória mindenre elegendő! ). 
Felesleges a célozgatás, mert ahhoz, hogy meg tudjuk jelölni 
a határokat, el kell látnunk odáig. Ezért a kérdésre inkább egy 
idézettel válaszolok: 


Richard Bach művében, Jonathan a renitens, saját korlátait fe- 

szegető sirály távozásakor a következő tanácsot adja Fletcher 

sirálynak: ,Ne higgy a szemednek. Amit azzal látsz, csupa 
korlát." Nincs határ. 

Détári István 

istvan.detariGogetronics.hu 

A szerző a Getronics (Magyarország) Kft. tanácsadója 

MCSE, MCSA, MCDBA, CCNP 


Felhasznált szakirodalom 





A DHLP rejtett szépségei — IL. 


Előző alkalommal telepítettünk és címtartománnyal szereltünk fel egy DHCP- 


kiszolgálót, majd elkalandoztunk a DNS- és DHCP-integráció területére. Most még 
egy rövid időre visszatérünk a scope-okhoz, és alaposan szemügyre vesszük, mi- 
lyen részei vannak, és milyen lehetőségekkel rendelkezünk a címtartományok ki- 


terjesztésére. 


A scope központi fogalom a DHCP-szolgáltatás kialakításakor. 
Miután a varázsló segítségével létrehoztunk egyet, érdemes 
alaposan megvizsgálni a kezelőfelületet, hogy lássuk, hogyan 
finomíthatjuk még a beállításokat. 
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E DHCP-kiszolgáló egy scope létrehozása után 


A címtartomány belülről 


A scope tulajdonságairól és a legfontosabb opciókról már ér- 
tekeztünk, de a kizárt és lefoglalt címekkel (reservations), va- 
lamint a speciális scope tulajdonságokkal még nem foglalkoz- 
tunk. 

A fenti ábrán látható, hogy a címtartomány definiálása mellett 
azonnal meg kell adni azokat a címeket vagy cím-intervallu- 
mokat, amelyeket a teljes címtartományon belül szeretnénk 
kizárni a kiadható IP-címek közül. A kizárás persze nem köte- 
lező, de néha kifejezetten hasznos. Ha például vannak állan- 
dó, statikus IP-címet igénylő kiszolgálók vagy egyéb aktív esz- 
közök, switchek, nyomtató-szerverek, és azok címei beéke- 
lődnek egy érvényes címtartományba, a kizárás módszerével 
megakadályozhatjuk, hogy a DHCP-szerver egy másik ügyfél 
rendelkezésére bocsássa az ominózus azonosítót. Jobb helye- 
ken, ahol ezek az eszközök eleve egy elkülönült címtarto- 
mányból részesülnek, vagy lefoglalt címeket kapnak a hostok, 
erre külön nincs szükség. A kizárás funkció ott is használható, 
amikor két DHCP-szolgáltatással magasabb rendelkezésre ál- 
lást szeretnénk biztosítani, — de erről majd később. 


A kiadott címek listája 


Nem elhanyagolható haszonnal jár, ha szeretnénk bepillanta- 
ni az épp kiadott címek listájába. Ha egy állomás MAC-címét 
szeretnénk megtudni, vagy csak egyáltalán az IP-címére va- 
gyunk kíváncsiak, a kiadott címek listájának táblázatát kell át- 
böngésznünk. A konzol információkat is szolgáltat a bérletek 
kiadásáról és lejárati idejéről is. Ha szükséges, törölni is lehet 
egy rekordot, ám ez csak nagyon körültekintő módon ajánlott. 
Egy cím törlése hasonló hatással van a hálózatra, mint amikor 
egy bérlet véglegesen lejár, azzal a különbséggel, hogy a bér- 
letet használó ügyfél aktív maradhat, és használhatja a címet, 








— hisz semmiféle értesítést a rekordtörlésről nem kap. A cím 
ráadásul felszabadul, amit éles környezetben egy másik állo- 
más megkaphat, — ezáltal két állomás is ugyanazzal a címmel 
rendelkezhet. Csak akkor javaslom tehát bérlet törlését, ha az 
IP-címet szeretnénk felvenni a kizárt vagy a lefoglalt címek 
közé. Az utóbbi esetben az ügyfél oldalán mindenképp el kell 
végezni egy ,ipconfig /renew" műveletet is. 


A lefoglalt címek listája 


Gyakran összekeverik a kizárt és a lefoglalt címeket, holott ez 
utóbbiak más célt szolgálnak. Ha szeretnénk minél több ügy- 
felet a DHCP-szolgáltatás kliensei között tudni, de néhány 
esetben bizonyosan ugyanazt az IP-címet kellene kiadnunk 
egy-két állomásnak, a lefoglalt címek közé kell felvennünk az 
ügyfél adatait, és mindkét kívánságunk teljesült. A lefoglalt cí- 
mek funkció azért működik, mert a DHCP képes a címigény- 
lő csomagból megállapítani az adott állomás hardver-címét 
(Ethernet hálózat esetén ez a MAC address), és ha talál ehhez 
a bejegyzéshez egy lefoglalt címet, azt fogja minden esetben 
kiajánlani. A reservations működési elvéből következik, hogy 
ha egy címet kizártunk, akkor az nem lehet egyben lefoglalt 
cím, és fordítva, a lefoglalt címeket nem szabad kizárni. Bár 
látszólag triviális dologról van szó, mégis nagyon gyakori kon- 
figurációs hiba, hogy a lefoglalt címeket megpróbálják kizár- 
ni, ,nehogy véletlenül is más kapja meg", vagy mert ,a lefog- 
lalt cím nem játszik, az másra nem használható, tehát ki kell 
zárni". Mindez a fogalmak pontatlan ismeretéből fakad. A há- 
rom címtípus egymáshoz való viszonyát egy ábrán is megjele- 
nítettem, hogy az olvasó már soha többé ne tartozzon az ilyen 
hibákat elkövetők közé. 





E A címtartomány, a lefoglalt címek és a kizárt címek vi- 
szonya 


Visszatérve a lefoglalt címekhez: ismernünk kell, miként visel- 
kedik a kiszolgáló, ha olyan címek közül foglalunk le egyet, 
amely korábban a címtartomány normál címei közé tartozott, 
és amelyet esetleg egy másik állomás már igénybe vett. Ilyen- 
kor vagy meg kell várnunk a bérlet végét, vagy az adott ügy- 
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A DHCP rejtett szépségei / 


ARA felet rá kell szorítanunk, hogy ,engedje el" a címet. 


NT/2000/XP. rendszereknél az ,ipconfig /release" 
dug] paranccsal érhetjük el ezt, a Win9x világban pedig a 
winipcíg névre hallgató kis grafikus program siet a 
segítségünkre. Egyébként a bérlet kiadása szintén 
nem automatikus, — vagyis attól, hogy a lefoglalt címet rögzí- 
tettük, még nem kapta meg azt az ügyfél. A kliensgépen kia- 
dott ,ipconfig /renew" parancs azonban általában meghozza 
gyümölcsét: a friss lefoglalt címet. 
A lefoglalt cím nagyon hasznos szolgáltatás. Egy hálózatban 
rengeteg olyan állomás működhet, amely állandó IP-címet 
igényel. Háromszáz munkaállomáshoz már akár féltucat 
switch, 10-20 hálózati nyomtató, több szerver tartozhat, ame- 
Ilyeket mind-mind állandó címmel kell ellátni. Egy IP-cím vagy 
hálózati maszk-váltás rengeteg munkával jár, ha statikus cí- 
mekkel dolgozunk. A manuális munka ugyanakkor mindig 
magában rejti a hibázás lehetőségét is. Könnyen kimaradhat 
egy DNS-cím vagy az idő-szerverek megadása, s máris meg- 
jósolhatatlan hibák tűnnek fel a rendszerben. A lefoglalt cí- 
mekkel mindez elkerülhető, a változások bizonyosan érvény- 
re jutnak. Hasonló módon lehet leszerelni azokat a megoldás- 
szállítókat, akik egy monitorozó, tarifikáló vagy egyéb beren- 
dezést szállítanak, s kötik az ebet a karóhoz a statikus IP- 
címért. Bőven megteszi egy lefoglalt cím is. Egy tökéletes há- 
lózatban szinte csak a WINS és DHCP-kiszolgálók rendelkez- 
nek statikus címekkel. 


Műveletek a címtartománnyal 


Ahhoz, hogy egy scope ellássa feladatát, aktiválni kell. Csak 
aktív scope bocsát ki IP-bérleteket. A művelet rendkívül egy- 
szerű, csupán a jobboldali egérgombbal kell kattintani a cím- 
tartományon, majd az aktiválást választani. A scope 
deaktiválásával megszűnik a korábbi funkciója. Csak nem ak- 
tív címtartományt lehet törölni. 
A címtartomány körül a legnagyobb felhajtás akkor keletkezik, 
amikor a rendelkezésre álló címek elfogynak. A bérletidő rö- 
vidítésével lehet még orvosolni a címéhséget, a hosszú távú 
megoldás azonban mindenképpen a scope átalakítása. 
Elsőre azt gondolhatnánk, hogy kényelmesen átállítjuk a cím- 
tartomány tulajdonságlapján a kezdő és a végső címet, sőt 
akár az alhálózati maszkot, és már készen is vagyunk. Sajnos, 
ez egy járhatatlan út. A szabvány szerint nem nagyon lehetne 
nyomon követni, hogy melyik bérletet milyen címtartomány- 
paraméterekkel adtuk ki. Sok kiadott cím kikerülhetne az ér- 
vényes bérletintervallumból, esetleg érvénytelen lenne az al- 
hálózati maszk, — egyszóval kavarodás lenne. Három lehető- 
ségünk maradt a probléma megoldására: 

HA a scope kiterjesztése 

mA az alhálózat újrakonstruálása (resubnetting) 

A Superscope-ok alkalmazása (multinetting) 


A címtartomány kiterjesztése 


A scope megváltoztatásának egyetlen járható útja a kiterjesz- 
tés. Ha az eredeti címtartomány kisebb, mint az alhálózati 
maszkja alapján az lehetséges lenne, akkor mód van a tarto- 
mány végső címének kitolására. Például a 192.168.0.1 - 
192.168.0.100 címtartományunkat 255.255.255.0 maszkkal, 
kiterjeszthetjük 192.168.0.254-ig mindenféle káros következ- 
mény nélkül. A kiterjesztés lehet többlépcsős is, és az alháló- 
zat elméleti határáig tarthat. Korábban (a Windows NT 4.0 
szervernél) csupán 32-esével lehetett a tartományt kiterjeszte- 
ni, vagyis 100-ról 132-re kellett volna növelni a tartomány ha- 





tárát. A SP6-tól kezdve ez a kötöttség már nem létezik. 
Amennyiben eleve belefoglaltuk a scope-ba az alhálózat en- 
gedte összes címet, ezt a módszert nem alkalmazhatjuk. 


Az alhálózat újrakonstruálása (resubnetting) 


Ha egy subnet maskot úgy alakítunk át, hogy az egyre kisebb 
számokat tartalmaz, akkor az alhálózatban rendelkezésre álló 
címek száma megnő. Nagyszerű, épp ezt szeretnénk. Csak- 
hogy ennek komoly ára van. Az alhálózati maszk meghatároz- 
za az alhálózatot, vagyis: új maszk, új hálózat. Ezt az új háló- 
zatot meg kell ismertetni valamennyi útválasztónkkal, át kell 
állítanunk az összes statikus IP-címmel rendelkező állomá- 
sunkat, továbbá el kell dobnunk a már létező scope-ot és az 
összes bérletet, létre kell hozni egy újat. Erre azért van szük- 
ség, mert egy scope az alhálózati maszkja alapján csak egyet- 
len logikai alhálózatnak szolgáltat címet, kettőnek nem. Ha 
sok géppel dogozunk, és nem kivitelezhető a művelet rövid 
idő alatt, akkor biztosítani kell a két hálózat közötti kommu- 
nikációt az alapértelmezett átjárók átkonfigurálásával. Summa 
summarum, az alhálózati maszk megváltoztatása hatékony 
ugyan, de nem sétagalopp. 


Superscope-ok alkalmazása 
A superscope a Windows NT4 SP2 verziója óta ismert foga- 


lom, lényegében a címtartományok egybefogását jelenti. 


IP Address Managment. 
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E Két címtartomány alkotta superscope 


Ha szeretnénk egyetlen fizikai alhálózaton több logikai (/P) al- 
hálózatot üzemeltetni, azt csupán scope-ok segítségével nem 
könnyű megvalósítani. A DHCP-kiszolgáló minden ügyfélnek 
a legelőször aktivált címtartományból hajlandó címet adni. 
Csupán azt tehetnénk, hogy egy második hálózati kártyát is 
üzembe helyeznénk, majd ellátnánk az új alhálózatból szár- 
mazó címmel, végül létrehoznánk a második scope-ot is. Min- 
den további (logikai) alhálózat egy további hálózati kártyát 
igényelne. Ettől a barkácsolástól kímél meg minket a 
superscope. 

Tegyük fel, hogy van egy hálózatunk, ahol minden aktív esz- 
köz egyben DHCP-ügyfél is. Szeretnénk elkülöníteni az aktív 
elemeket cím szerint is a munkaállomásoktól. Mivel a 
switchekkel csak a hálózati adminisztrátorok kommunikálnak 
az IP-címeken keresztül, a nem túlságosan nagy forgalom 
miatt az elkülönítés után nem keletkezik szűk keresztmetszet. 
A superscope segítségével a feladat megoldása könnyű. 
Először létre kell hoznunk egy 192.168.0.11-192.168.0.254 
címtartományt a megfelelő alhálózati maszkkal és egyéb op- 
ciókkal. Ezután el kell készíteni egy második scope-ot is, 
amely a 172.16.0.0/24 hálózatot foglalja magában, ám rögtön 


ma 
- 
- 
- 
(D 


valamennyi címet ki kell zárni, az első hármat kivéve. Ez 
utóbbiakat mint előre lefoglalt címet kell rögzíteni a hálózati 
kapcsolók MAC címével együtt. Végezetül létre kell hozni egy 
superscope-ot, majd a két korábbi címtartományt a 
superscope tagjává kell tenni. 


DG. 
SIZA IP Addresst: 172.16.0.245 


k. EZ SS /IP Address2: 192.168.0.254 
ISZRG ai 


mt 





192.168.0.14 





. 172.16.0.1 192.168.0.13 





192.168.0.12 




















192.168.0.11 


DHCP-kiszolgáló 
Scopet: 172.16.0.0/24 
Scope2: 192.168.0.0/24 


B Egy alhálózat két logikai IP-hálózattal 


Ezzel készen is vagyunk. A két alhálózat közötti kommuniká- 
ciót az alapértelmezett átjárón felvett útvonalbejegyzés segít- 
ségével lehet biztosítani, szükség esetén szűrve az útvonalat 
használó állomások számát, címét. (Csak zárójelben jegyzem 
meg, hogy a superscope-ok nem csak a helyi hálózatokon tá- 
mogatják a több logikai alhálózatot, hanem távoli — 
routereken túli — hálózatokon is. Ezeket a képességeket a 
DHCP Relay Agent tárgyalásakor még érintjük. A fenti 
172.16.0.0/24 jelölés a továbbiakban többször szerepel majd. 
Azt jelenti, hogy az alhálózati maszkban 24-db 1-es szerepel, 
ami decimálisan 255.255.255.0-t jelent.) 

A superscope-ok fenti képességei hasznosak a címtartomá- 
nyok kiterjesztésekor. Elegendő egy második címtartományt 
definiálni, majd az első scope-pal egy superscope-ot alkotni, 
a címtartomány kiterjesztése máris megtörtént. 

A címtartományok összefogása az alhálózat újrakonstruálása- 
kor is jó szolgálatot tesz. Az új alhálózat bevezetése egy 
superscope segítségével a legegyszerűbb. Bele kell foglalni az 
új és a régi címintervallumokat, a régi scope-ot pedig úgy kell 
módosítani, hogy valamennyi címét ki kell zárni. Az ügyfelek 
újraindulásakor mindegyik az új intervallumból kap majd cí- 
meket. A statikus állomások, valamint az útválasztók konfigu- 
rálását nem lehet megúszni. 


Superscoping, multinetting, supernetting 


MCP vizsgára készülő szakértő-jelöltek tapasztalhatták, hogy 
néhány vizsgakérdés előszeretettel próbál zavart kelteni a fen- 
ti fogalmakkal kapcsolatban a vizsgázók fejében. Az alhálóza- 
tok kialakítása és a superscope fogalmának ismeretében most 
megragadom az alkalmat, és amennyire lehetséges, tisztázom 
az egymással részben összefüggő kifejezéseket. 

A multinetting azt a szituációt jelenti, amikor egy fizikai alhá- 
lózaton több logikai (IP) hálózatot hozunk létre. A multinetting 
elméletileg nem kötődik a DHCP fogalmakhoz, így a 
superscope-hoz sem, elképzelhető ugyanis multinet DHCP 
nélkül. Gyakorlatilag azonban ilyen szituáció csak kivételes 
esetekben fordulhat elő, így a multinetting szinte mindig a 
superscope fogalmával együtt jelenik meg, hisz a superscope 
a multinet DHCP-támogatását takarja. 





A superscoping és a supernetting összehasonlításá- 
nak az az alapja, hogy lényegében ugyanazt a célt 
szolgálja mindkét eljárás, habár teljesen eltérő mó- 
don közelítik meg a problémát. 
A superscoping alapvető célja a DHCP-ügyfelek ál- 
tal felhasználható címek számának növelése az alhálózati 
maszk változtatása nélkül. Ennek érdekében újabb IP- 
alhálózatokat alkalmaz, és egy közös superscope-ot hoz létre. 
A megoldás előnye, hogy viszonylag gyors és egyszerű mód- 
szer, a meglévő IP-címek nem változ- 
nak, és igénytelen megoldás, 
amennyiben nem szükségszerű, hogy 


- 


A superszoping És a címtartományok egybefüggőek le- 
k gyenek. A 192.168.0.0/24-hez hozzá 
a supernetting lehet fűzni a 192.168.3.0/24-et, de 


akár a 172.16.0.0/24-et is. A módszer 
hátránya, hogy szűk keresztmetszetet 
hoz létre, hiszen a különböző alháló- 
zatok között az adatforgalom az 


összehasonlításának 


a2 az alapja, hogy 


alapértelmezett átjárón keresztül 
lényegében ugyanazt áramlik, továbbá az állomásoknak 
nincs közös broadcast címe. 
a célt szolgálja A supernetting célja ugyancsak a 


kiosztható címek növelése, de a fenti 
megoldástól eltérően az alhálózati 
maszk változtatásával. Minél kisebb 
számok szerepelnek a maszkban, an- 
nál több host-cím áll rendelkezésre. A 


mindkét eljárás, ha- 


bár teljesen eltérő 


módon közelítik meg . 255.255.255.0 maszk 254 lehetséges 
KN állomáscímet — jelent, míg a 
a problémát. 255.255.252.0 már több mint négy- 


szer ennyit. Ha az eredeti címtarto- 

mány 192.168.0.0/24 volt, az új pe- 

dig — 192.168.0.0/22, akkor a 
192.168.0.1-192.168.0.254 címintervallum 192.168.3.254-ig 
bővül. 
A supernetting egy folytonos címtartományt eredményez, a 
DHCP támogatása pedig megoldható egyetlen scope-pal. 
Nem keletkezik szűk keresztmetszet, és van közös broadcast 
cím is. Hátránya a módszernek, hogy minden cím megválto- 
zik, még akkor is, ha egy host névlegesen ugyanazt a címet 
kapja vissza. A 192.168.0.100/24 más jelent, mint a 
192.168.0.100/22. 
Összegzésül azt mondhatjuk, hogy a superscoping és a 
supernetting ugyanazt a célt (felhasználható címek növelése) 
eltérő módszerekkel, előnyökkel és hátrányokkal valósítja 
meg. A konkrét szituáció és preferenciák határozzák meg, 
hogy melyik módszer a célravezetőbb. 
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Internet Information Services 6.0 


Internet Information 
jervices 5.0, III. rész 


Levelező-szolgáltatások a Windows 
Server 2003-ban: az SMTP 


Az SMTP szolgáltatás 


Az SMTP rendszerszolgáltatás a Windows 2000-hez képest 
egyetlen dolog (az LDAP útválasztás) kivételével nem tartal- 
maz igazán sok újdonságot. A következő leírás így a Windows 
2000 üzemeltetőinek is jó szolgálatot tehet. 


KMEZEETEZTTTETETTÜSTZTT STT Dix 
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4 Internet Information Services 
"9 SERVER2003 (local computer) [$G server2003.falatrax2003.hu 
4). J Application Pools 
4). J Web Sites 
4) -) Web Servke Extenslons 
24 
ST Domains; 
£2 current Sessions Stop 
Pause 


tew , 
New Window from Here 


Rename 
Refresh 


Properties 
Help 





Local (Defaut) 
[EG 60e4ac6f-970d-40de-a459-S7I14bcScebf9.. msdcs... Local (Norrnal) 









start the server 





G Az SMTP MAC konzolja - itt kezelhetjük a virtuális ki- 
szolgálókat és az általuk kiszolgált tartományokat 


Egy számítógépen természetesen egynél több virtuális kiszol- 
gáló is futhat párhuzamosan, ha egymástól különböző IP- 
címen és/vagy portcímen érjük el őket. A portcím megváltoz- 
tatása azért nem szerencsés, mert a levelezőrendszerek világ- 
szerte a szabványos SMTP portot, a TCP 25-öt használják. 


DEZE Lake era ását ai E 2]XxI 


General I Access] Messages ] Delivery ] LDAP Routing ] Security ] 


Default SMTP Virtual Server 





IR address: 





TT Limit number of connections to: 


Advanced... I 
0 


Connection time-out (minutes): 


1 
B A virtuális kiszolgáló általános tulajdonságai 


A virtuális kiszolgáló tulajdonságlapjának , General" oldalán 
határozhatjuk meg a kiszolgáló IP címét (illetve az Advanced 
gombra kattintva a használt portcímet is). A ,Limit number of 
connections to:" mező beállításával az SMTP kiszolgáló felé 
nyitható egyidejű kapcsolatok számát határozhatjuk meg. Ha 
a kapcsolatok száma elérte a maximumot, a kiszolgáló a to- 
vábbi beérkező kérelmeket elutasítja. A Connection time-out: 


mezőben korlátozhatjuk az SMTP kapcsolatok maximális idő- 
tartamát (egy kapcsolaton keresztül több levél is elküldhető, 
amíg a kapcsolat fennáll). 

Ugyanitt találjuk, bár az ábrán már nem látszik a naplózás 
beállításait. Az ,Enable logging" mezőben bekapcsolhatjuk a 
naplófájlok készítését, a Properties gombra kattintva 


Biztonsági beállítások 


A tulajdonságlap következő oldalán (, Access") a kiszolgálóva 
történő kommunikáció biztonsági beállításait találjuk. Az első 
gomb (, Authentication") a bejelentkezési protokollok beállítá- 
saihoz vezet. 





Select acceptable authentication methods for this resouce. 





No user name or password reguired. 


[7 Basic authentication 


The password will be sent over the network in clear text using standard 
commands. 


T Reguires TLS encryption 
Default domain: 


e —k,rmrmr,—,—,, 


[7 Integrated Windows Authentication 


The client and server negotiate the Windovis Security Support Provider 
Interface. 


Cancel I Help 


E Bejelentkezési protokollok. Az alapértelmezés csak az 
Anonymous" 





A Windows Server 2003 telepítésekor ezen a panelen csak a 
névtelen hozzáférés (Anonymous access) van engedélyezve, 
azaz a kiszolgálóra biztonsági okokból nem lehet bejelentkez- 
ni. A (saját domainbe) beérkező leveleket a kiszolgáló így is 
elfogadja. Mivel azonban a levéltovábbítási (mail relay) beál- 
lítások az idegen tartományba küldött levelek küldését előze- 
tes bejelentkezéshez kötik (lásd kicsit később), a ,normális" 
működéshez itt be kell állítanunk a lehetséges bejelentkezési 
protokollokat is: 

A Basic Authentication: a protokollok szabványos fel- 
használóazonosítási módja, ahol a felhasználónév és a 
jelszó a hálózaton titkosítatlanul utazik. Ez nyilvánva- 
lóan nem biztonságos, ezért ajánlott bekapcsolni a TLS 





titkosítás kikényszerítését (, Reguires TLS encryption"). 
A titkosított TLS csatorna kiépítéséhez azonban egy- 
részt kiszolgálótanúsítvány, másrészt további beállítá- 
sok szükségesek (erről a következő pontban lesz szó). 
Ha a bejelentkezéskor a felhasználó tartományt nem, 
csak felhasználónevet és jelszót ad meg, a Windows a 
saját tartományában fogja keresni a felhasználót. Ha 
azt szeretnénk, hogy az alapértelmezett keresési tarto- 
mány ettől különböző legyen, megadhatjuk a , Default 
domain" mezőben. 

TA Integrated Windows Authentication: Windows környe- 
zetben (Windows SMTP kiszolgálók illetve ügyfél kö- 
zött) jobb megoldás a Windows beépített azonosítási 
protokolljának (Windows Security Support Provider In- 
terface — SSPI) használata. 

Ha az Integrated Windows és a Basic Authentication egyaránt 
engedélyezve van, a Windows az Integrated azonosítást fogja 
előnyben részesíteni. 


A TLS kommunikáció 


A TLS az SSL-hez hasonló (sőt, tulajdonképpen annak utódjá- 
nak tekinthető) titkosított csatorna, ahol a csatorna kiépítésé- 
hez szükség van a kiszolgáló tanúsítványára. (Ez a tanúsítvány 
a titkosító kulcs továbbításán kívül még a kiszolgáló hiteles 
azonosítására is alkalmas.) Az SMTP kiszolgálóval való kom- 
munikáció titkosítására is a TLS-t használjuk, de a fentiek ér- 
telmében mielőtt ilyen csatorna épülhetne, a kiszolgálónknak 
rendelkeznie kell egy megfelelő nyílt kulcsú tanúsítvánnyal. 
A virtuális kiszolgáló tulajdonságlapjának , Access" oldalán, a 
,Secure communication" mezőben két gombot találunk. A 
Certificate" nyomógomb a kiszolgálótanúsítvány kezelésére 
használható, a , Communication" gomb segítségével pedig a 
majdan létrehozott TLS csatorna beállításait érhetjük el. Ez 
utóbbi nyomógomb egészen addig tiltott, míg a kiszolgáló 
nem rendelkezik érvényes tanúsítvánnyal. 

Ha a , Certificate" nyomógombra kattintunk, elindul a , Web 
Server Certificate Wizard", ami segít nekünk a tanúsítvány ké- 
résében (egyébként később a kezelésében, sőt törlésében is). 
Ha új tanúsítványt kérünk (ehhez természetesen szükség lesz 
majd egy tanúsítványkiadó ICAJ szolgáltatásra is, de az egy 
másik cikksorozat témája), arra vigyázzunk, hogy a tanúsít- 
vány a kiszolgáló internetes (DNS) nevére szóljon, különben 
a tanúsítvány ellenőrzésekor azt az ügyfelek nem fogadják 
majd el. 


HIS Certificate Wizard Éz 


Your Síte"s Common Name 
Your web sites common name ís its fully gualified domain name. 









Type the common name for your site. I the server is on the Intemet, use a valid DNS 
name. Ifthe server is on the intranet, you may prefer to use the computers NetBIOS 
name. 


Ifthe common name changes, you will need to obtain a new certificate. 


Common name: 
server2003 falatrax2003.hu 








c Back Next 


— Eme ] 


E A SMTP-kiszolgáló tanúsítványában a kiszolgáló teljes 
és érvényes DNS-neve szerepeljen 








n.net Gaz ERT gy vw i 


Ha a kiszolgáló tanúsítványa elkészült, a Communications 
gombra kattintva a következő dialógusablakot látjuk: 





Once a valid key certificate is installed, you can reguire that access take 
place on a secure channel. 





Access can also be limited by the strength of the enciyption. Select this 
option only if 128-bit encryption is supported on this computer. 


TI Reguire 128-bit encryption 


CST. tre [en] 





E A TIS beállítások dialógusablaka 


A tanúsítvány telepítésétől kezdve a TLS csatorna kiépíthető, 
de használata nem kötelező. Ha azonban itt (ahogy az ábrán 
is látható) bekapcsoljuk a ,Reguire secure channel" opciót, 
titkosítatlan kapcsolat egyáltalán nem jöhet létre a kiszolgáló- 
val. Egy Internetes üzemben is működő SMTP szolgáltatásnál 
éppen ezért ezt ne kényszerítsük ki (itt), hiszen az Internetről 
érkező levelek kiszolgálói ezt nem biztos, hogy támogatják. 
Ha az azonosításhoz szeretnénk a titkosított csatornát, jobb, 
ha az előző (,Authentication") dialógusablakban, a Basic 
Authentication mezőben kapcsoljuk be a TLS-t, ekkor ugyanis 
csak akkor igényel a kiszolgáló titkosított kapcsolatot, ha erre 
az azonosításra sor kerül. 


Kapcsolódás, Mail Relay 


A kiszolgáló tulajdonságlapjának , Access" oldalán található 
következő nyomógomb a ,Connections" feliratot viseli. A 
gombra kattintva beállíthatjuk, hogy a kiszolgálót milyen IP 
címekről lehet elérni (az alapértelmezés az, hogy mindenhon- 
nan). Ha tudjuk, hogy az SMTP szolgáltatást csak adott IP-cím 
tartomány(okjból érik el, itt beállíthatjuk ezt a korlátozást. Ha 
azonban a kiszolgálónk az Internetről is fogad leveleket, hagy- 
juk az alapértelmezést. 

A következő nyomógomb a , Relay...". 








Relay Restrictions 
Select which computer may relay through this virtual server: 
(7 Only the list below 
C All except the list below 
Computers: 








IP Address (Mask) / Domain Name 
192.168.0.0 (255.255.255.0) 


e Granted — 






s 








E Levéltovábbítási (Mail Relay) korlátozások. Alapértel- 
mezésben a fenti lista teljesen üres! 
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Az előbbi, ,Relay Restrictions" ablakban a levélto- 
vábbítást (Mail Relay-t) szabályozhatjuk. Az SMTP 
szolgáltatás elfogad és kézbesít minden bejövő leve- 
let, amelynek címzettje valamelyik, általa kezelt tar- 
tományba tartozik. Ha azonban a címzett postaládá- 
ja egy másik kiszolgálón található, a levelet az SMTP szolgál- 
tatásnak továbbítania kellene. Ez utóbbi lépés azonban már 
nem általánosan engedélyezett, hiszen ezt a , trükköt" szeretik 
kihasználni világszerte a kéretlen reklámlevelek kiküldéséhez. 
Az SMTP szolgáltatás csak akkor hajlandó erre, ha a ,külső" 
levelet küldő ügyfél a fenti dialógusban felsorolt IP-cím tarto- 
mányból érkezik (ez a lista frissen telepített kiszolgálónál üres, 
ide kézzel felvehetjük a belső hálózatunk IP címeit), illetve, 
ha a levél küldése előtt az ügyfél felhasználónevével és jelsza- 
vával bejelentkezik (, Allow all computers which successfully 
authenticate to relay..."). A bejelentkezés protokollja a koráb- 
ban bemutatott ,Authentication" dialógusban állítható be 
(emlékszünk: Basic vagy Windows Integrated). 

A bejelentkezés szükségességéről azonban értesítenünk kell a 
felhasználókat, különben a levél elküldésekor a kiszolgáló hi- 
bával visszautasítja őket: 





€ The message could not be sent because one of the recipients was rejected by the 


servet. se jén e-mail address was relaytest hotmail com. Subject R 
Arc 50 5. 7 1 






alhost. Protocot SMTP. Server Response: 


Unabe to relayt for relastestésholmal com JPort: 25, Secure(SSL): No, Server Error 


a A tipikus hibaüzenet: ,, Unable to relay..." 


A bejelentkezéshez a levelezőprogramban be kell állítanunk a 
kimenő kiszolgálóhoz történő bejelentkezést: 


Outgoing Mail Server — 


I My server reguires authentication Settings... 
2 


Logon Information — 








B A levelezőprogramban kapcsoljuk be a kimenő kiszol- 
gálóhoz történő bejelentkezést! 


A bejelentkezés használhatja a beérkező levelek letöltéséhez 
megadott felhasználónevet és jelszót (,Use same settings as 
my incoming server"), de megadhatunk ettől teljesen eltérő 
adatokat is (, Log on using..."). 


Az üzenetek beállításai 

Térjünk vissza a virtuális kiszolgáló beállításaihoz! A kiszolgá- 
ló tulajdonságlapjának ,Messages" oldalán a beérkező üzene- 
tek és kapcsolatok korlátozásait állíthatjuk be (az ábrán az 
alapértelmezések): 





DILET det e elet ESezz d díj 


ű Z2ixi 
General] Access  Messages ] Delivery ) LDAP Routing ) Security ) 
Specify the following messaging information. 


essa 2048 





[7 Limit session size to (KB). 


[7 Limit number of messages per connection to: 


[7 Limit number of recipients per message to: 100 
Send copy of Non. Delivery Report to: 
Badrmail directory: 


E MnetpubtmailroottB admail Browse... 


E A beérkező levelek beállításai 


Limit message size to: A beérkező levelek maximális mérete 
egyenként (2MB). A kiszolgálónkhoz csatlakozó távoli SMTP 
kiszolgáló a levél küldése előtt ezt az értéket lekérdezheti, és 
ha a küldendő levél mérete meghaladja az itt beállított érté- 
ket, a levelet meg sem kísérli elküldeni (erről egy kézbesítet- 
lenségi jelentésben [Non Delivery Report, NDRI értesíti az 
eredeti feladót). 

Ha a kiszolgáló nem kérdezi le a maximális levélméretet, és 
megkísérli elküldeni nekünk a levelet, az SMTP szolgáltatás az 
itt beállított határ elérése után hibaüzenettel megszakítja a 
kapcsolatot: 





€ The message could not be sent because its size exceeded the servers limit. You can 
use the option, located in Tools JAccounts I Properties [ádvanced, 10 break messages 
into smaller parts. Subject "N. 
SMTP, Server Response:[552 4.3.1 Message size exceeds fixed maximum message 
(size ]Port: 25. Secure(SSLENo, Server Error 552. Errör Number: UZBUDCCCBŰ " 










B A túl nagy méretű leveleket a kiszolgáló visszautasítja 


Ha két SMTP kiszolgáló egymással felépített egy kapcsolatot, 
a hálózati terhelés csökkentése érdekében egy kapcsolaton 
keresztül több üzenetet is elküldhetnek (egymás után). A Limit 
session size to: mezőben az egy kapcsolaton keresztül beér- 
kezett levelek összesített méretét állíthatjuk be (ebbe csak a 
levelek törzsének mérete számít, a fejlécinformáiók nem). Az 
alapértelmezés itt TOMB, ez tehát az egy kapcsolaton keresz- 
tül (egy szuszra") beküldött levelek összesített mérete. 
Ugyanide tartozik a következő opció (Limit number of 
messages per connection to:), ahol az egy kapcsolaton belül 
beküldhető üzenetek maximális száma (10) határozható meg. 
Az utolsó opció (Limit number of recipients per message to:) 
az egy üzenetben található címzettek maximális számát kor- 
látozza. A beállítható minimális érték itt az SMTP szabvány 
szerint 100, ezért ez az alapértelmezés is. A korlátok elérése- 
kor az SMTP kiszolgáló bontja a kapcsolatot illetve visszauta- 
sítja a kérdéses levél kézbesítését. 

A kézbesíthetetlen üzenetekről az SMTP kiszolgáló az eredeti 
feladónak hibaüzenetet, kézbesíthetetlenségi jelentést (Non- 
Delivery Report, NDR) küld. Ha szeretnénk, a szolgáltatás 
minden NDR-ről másolatot küldhet nekünk egy megadott 
címre (Send a copy of Non-Delivery Report to). 


A Badmail könyvtár 


Az NDR-t a kiszolgáló ugyanúgy kézbesíti, mint bármilyen 
már e-mailt. Ha az NDR kézbesíthetetlen, arról természetesen 


újabb NDR már nem készül, hanem az üzenet az SMTP ki- 
szolgáló ,Badmail" könyvtárába kerül. 

A könyvtár alapértelmezésben ,C:MnetPubWnailrootYBadmail" 
elérési úton található, de a Badmail directory ablakban ezt 
módosíthatjuk. 

Ha a kiszolgálónk (például hibás Mail Relay beállításoknak 
köszönhetően) kéretlen reklámlevelek százezreit próbálja ki- 
küldeni (ezek közül jópárat persze hibás címre), minden egyes 
próbálkozásról NDR készül. Mivel azonban az ilyen reklám- 
levelek feladói a legritkább esetben érvényes és létező címek, 
az NDR (sok-sok társával együtt) előbb vagy utóbb a Badmail 
könyvtárban köt ki. Ezért ezt a könyvtárat érdemes az operá- 
ciós rendszertől elkülönített partícióra tenni, esetleg kvótával 
korlátozni, mielőtt megtölti a rendszerpartíciót, működéskép- 
telenné téve ezzel a teljes számítógépet. 


A levelek kiküldésének beállításai 


Ha a kiszolgáló a kimenő levelet elsőre nem tudja továbbíta- 
ni (mert például a távoli kiszolgáló nem érhető el), adott ideig 
időközönként újra próbálkozik (erről néha értesíti a feladót), 
egészen addig, míg fel nem adja a próbálkozást (erről a tény- 
ről természetesen ugyancsak NDR készül). 


LETT SZA z d iv azaz 2]ad 


General ] Access ] Messages  Delívery I LDAP Routing ] Security ] 













Outbound Met sake 
First retry interval (minutes): (E I 
Second retry interval (minutes): Bo 
Third retry interval (minutes): (E 
Subseguent retry interval (minutes): 240 ! 


Delay notification 


n 2 

Expiration timeout: 2 Days 8. 
12 
2 


Local És — 


Delay notification: 


!  Expiration timeout: Days s]! 


Outbound Security... 








G A levelek kiküldésének beállításai 


A kimenő levelek újrapróbálkozási időtartamai (... retry 
interval) 15, 30, 60, majd 240 perc. A kézbesítési próbálkozá- 
sokról a rendszer 12 óránként értesíti a feladót (Delay 
notification), a próbálkozást pedig 2 nap múlva adja fel vég- 
legesen (Expiration timeout). 

Az Outbound Security... nyomógombra kattintva a kimenő 
levelek küldéséhez szükséges bejelentkezési információkat 
adhatjuk meg. A kézbesítés alapértelmezésben bejelentkezés 
nélkül (Anonymous) történik, de szükség esetén itt beállíthat- 
juk a bejelentkezési protokollokat (Basic, Integrated Win- 
dows), illetve a használatukhoz szükséges felhasználónevet és 
jelszót, valamint a TLS-csatorna használatának kikényszeríté- 
sét is. 

Ezek a beállítások az egész virtuális kiszolgálóra érvényesek. 
Később céltartományonként ettől eltérő beállításokat is 
megadhatunk majd. 











[7 Limit number of connections to: 1000 
Tíme-out [minutes]: jea 


[5 Limit number of connections per domain to: 100 








E A kimenő kapcsolatok beállításai 


Itt a kiszolgáló által egyidejűleg fenntartott kimenő kapcsola- 
tok számát korlátozhatjuk (Limit number of connections to), 
illetve egy-egy kapcsolat maximális várakozási időtartamát 
(Time-out). Ugyanitt állítható be a használt TCP port (25). Ez 
utóbbit általában nem ajánlott változtatni, hiszen a kiszolgá- 
lók Internetszerte ezen a porton várják a kapcsolatokat. A Li- 
mit number of connections per domain to mezőben azt hatá- 
rozhatjuk meg, hogy tartományonként (azaz címzett kiszolgá- 
lónként) egyidejűleg mennyi kimenő kapcsolatot építhet fel az 
SMTP szolgáltatás. 





fer ezte hola iss A € XI! 


Maximum hop count: 


B 


Masguerade domain: 


peemeteámem a — 


Fully-gualified domain name: 


fgerver2003. falatrax2003.hu Check DNS I 


Smart host: 


IT Attempt dírect delivery before sending to smart host 


TT Perform reverse DNS lookup on incoming messages 


A kimenő kapcsolatok további beállításait az , Advanced" 
gombra kattintva látjuk: 

Az internetes leveleket a kiszolgálók egymás között adják-ve- 
szik, míg az el nem éri a címzett kiszolgálóját. Azt elkerülen- 
dő, hogy a levelek a végtelenségi keringjenek a hálózatban, a 
Maximum hop count mezőben beállítható, hogy a levél 
mennyi ilyen kiszolgálók közötti továbbítás után számít kéz- 
besíthetetlennek. Ilyenkor az üzenetet a kiszolgáló már nem 
továbbítja, a feladónak pedig NDR-t küld. 

A Masguarade domain mezőben megadhatunk egy domain- 
nevet. Az SMTP-kiszolgáló ekkor erre a tartománynévre cseré- 
li a levelek kiküldésekor használt Mail From: mezőben talál- 
ható egyéb tartományneveket. Ez csak az SMTP-levelek for- 
ráskódjában látszik, a felhasználó által látható feladó neve és 
címe továbbra is az lesz, amit a levelezőprogramban megha- 
tároztak. - 

A Fully-gualified domain name mezőben a kiszolgáló teljes 
DNS-nevét adjuk meg. Az SMTP-szolgáltatás ezt a címet hasz- 
nálja a levelek továbbításakor kitöltött fejlécekben, illetve így 
köszönti a beérkező SMTP-kapcsolatokat is. 
Alapértelmezésben a kiszolgáló a DNS-szolgáltatás segítségé- 
vel minden kiküldött levél címzett tartományához megkeresi 
a felelős SMTP-kiszolgálót, és közvetlenül felveszi vele a kap- 
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csolatot. Ha azonban a kiszolgálónk egy tűzfal mö- 
gött van, beállíthatjuk úgy is, hogy minden kimenő 
levelet egy másik (SMTP) kiszolgálónak továbbítson, 
és majd ez a második szolgáltatás gondoskodjon az 
üzenet kézbesítéséről. A kiszolgáló DNS-nevét a 
Smart Host mezőbe írjuk be. Ha IP címet szeretnénk megad- 
ni, írjuk azt Ikapcsos zárójelek közé]. Ha bekapcsoljuk az 
Attempt direct delivery before sending to smart host lehető- 
séget, az SMTP-szolgáltatás minden esetben megpróbálkozik 
a közvetlen kézbesítéssel, és csak akkor továbbítja a levelet a 
Smart Host felé, ha a közvetlen kapcsolat nem építhető fel. 
Az utolsó opció a Perform reverse DNS lookup on incoming 
messages. Ha ezt bekapcsoljuk, az SMTP-szolgáltatás minden 
bejövő kapcsolat megnyitásakor ellenőrzi, hogy a távoli ki- 
szolgáló által a kapcsolatban (a HELO parancsban) megadott 
DNS-név megfelel-e annak az IP-címnek, ahonnan a kapcso- 
latot a valóságban felépítették. Bár ez biztonsági szempontból 
jónak tűnhet, vegyük figyelembe, hogy ebben az esetben min- 
den egyes beérkező kapcsolat egy DNS-lekérdezést eredmé- 
nyez, ezért lassítja a kiszolgáló működését. 


Az SMTP szolgáltatás hozzáférési jogosultságai 


A kiszolgáló tulajdonságlapjának LDAP Routing oldalát a kö- 
vetkező, POP3-mal foglalkozó részben mutatjuk majd be. A 
tulajdonságlapnak így már csak egy ismeretlen oldala maradt, 
ez pedig a szolgáltatás adminisztratív felügyeletének hozzáfé- 
rési jogait definiáló Security fül. Itt azokat a felhasználókat so- 
rolhatjuk fel, akik jogosultak az SMTP rendszerszolgáltatás 
beállításainak módosítására (Ők alapértelmezésben természe- 
tesen az Administrators csoport, valamint a rendszerszolgálta- 
tások által használ Local Service illetve Network Service fel- 
használói fiókok.). 


A kiszolgáló könyvtárstruktúrája 

Az SMTP szolgáltatás által telepítéskor létrehozott könyv- 
társtruktúra . alapértelmezett helye a  rendszerpartíció 
WnetpubWwnmailroot mappája. Ezen a könyvtáron belül az 
SMTP szolgáltatás az alábbi alkönyvtárakat hozza létre: 


IA Badmail: erről már volt szó, ide kerülnek a kézbesíthe- 
tetlen üzenetek (NDR-ek). 

H Drop: a virtuális kiszolgáló alapértelmezett (Default) 
tartományának célkönyvtára; minden beérkező levél 
(válogatás nélkül) ebbe a mappába kerül be. (Ha a 
POP3 szolgáltatást is telepítettük, a POP3 által kezelt 
tartományokba érkező levelek saját könyvtárakba ke- 
rülnek, de erről majd legközelebb.) 

A Pickup: az SMTP szolgáltatás folyamatosan figyeli en- 
nek a könyvtárnak a tartalmát, és ha itt olyan fájlt talál, 
amely tartalmilag megfelel egy RFC 822 (azaz SMTP) e- 
mailnek, kézbesíti azt. Így szinte bármely program ké- 
pes levélküldésre, ha alkalmas arra, hogy a merevleme- 
zen szöveges állományt hozzon létre. 

A Oueue: az SMTP által kiküldésre váró üzenetek (siker- 
telen küldési kísérlet esetén is itt maradnak meg, míg az 
újrapróbálkozási időtartam le nem telik) 

A SortTemp: átmeneti könyvtár, amelyet az SMTP kiszol- 
gáló levélküldéskor használ 


lis kiszolgáló létrehozásakor adhatjuk meg (később csak a 
MetaBase szerkesztésével módosíthatjuk). 


A szolgáltatás által kezelt tartományok (Domains) 


Egy SMTP virtuális kiszolgáló egynél több internetes tarto- 
mány (domain) üzeneteit is képes kezelni. Ezeket a tartomá- 
nyokat az Internet Services Manager MMC konzolfa Domains 
ága alatt láthatjuk: 




























[ÉG server2003.falatrax2003.hu Local (Default) 
[EG 6024ac6f-970d-40de-a459-S714bcScebf9.. msdcs... Local (Normal) 
JJ Web Servke Extensons 
S 2 Deak SMTP vtuel Server] Öinetcomhu 
SG Domains 
CÉ current Sessions 


B A virtuális kiszolgáló által kezelt tartományok 


A virtuális kiszolgáló alatt létrehozható tartományok két fő 
csoportba tartozhatnak: 

A Local: Helyi tartomány; minden ilyen tartomány fel- 
használóinak címzett levelet a virtuális kiszolgáló elfo- 
gad és kézbesít (elhelyezi azt a Drop könyvtárban) 

H Remote: Távoli tartomány; ezeket a bejegyzéseket két 
okból hozhatjuk létre. Az egyik az, hogy így adhatjuk 
meg egy-egy adott tartomány SMTP kiszolgálóival felé- 
pítendő kapcsolat alapértelmezéstől különböző beállí- 
tásait, a másik pedig, amikor az SMTP kiszolgáló , vál- 
lalja" hogy átmenetileg tárolja az idegen tartomány fel- 
használói címére érkező leveleket, hogy aztán az ille- 
tékes SMTP kiszolgáló innen tölthesse le azokat. 


A helyi tartományok között több altípust is találunk: 

A Default: az alapértelmezett helyi tartomány. Minden 
SMTP virtuális kiszolgáló rendelkezik legalább egy tar- 
tománnyal, ez pedig a Local (Default). Az alapértelme- 
Zett tartomány nem törölhető. 

A Alias: az alapértelmezett helyi tartomány , másik" neve. 
A kiszolgáló fogadja az ebbe a tartományba érkező le- 
veleket, és pontosan úgy jár el, mintha azok az 
alapértelmezett tartományba érkeztek volna (beleértve 
a kézbesítést az alapértelmezett tartomány Drop 
könyvtárába). Éppen ezért az Alias tartományok tulaj- 
donságlapja üres. 

AA Normal: Ilyen típusú tartományt akkor láthatunk, ami- 
kor az SMTP kiszolgáló tartományvezérlőn fut. Ez a 
(csúnya, GUID-nevű) tartomány felelős az Active 
Directory SMTP alapú replikációs forgalmának fogadá- 
sáért és továbbításáért. 

A Custom: Egyéni tartomány, a POP3 kiszolgáló hozza 
létre. 


A helyi tartományok beállításai 


A helyi tartományok tulajdonságlapja a következőképpen fest 
(kivéve az Alias tartományokét, mert az üres): 


Ea ká ele nyál ká Tej aza 
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General ] 


ég server2003.falatrax2003.hu 





This is the default domain 


CAlnetpubámailrootDrop Browse... 


Í 
Drop directory: 
[7 Enable drop dírectory guota ! 

l 


B Az alapértelmezett helyi tartomány beállításai 


Itt meghatározhatjuk a Drop könyvtár helyét (emlékezzünk: 
ide kerülnek a beérkező levelek), illetve bekapcsolhatjuk a 
könyvtár méretének korlátozását (,Enable drop directory 
guota"). Ha ez az opció engedélyezve van (és alapértelmezés- 
ben így van), a Drop könyvtár mérete nem haladhatja meg az 
SMTP kiszolgáló beállításaiban található Limit Message size to 
érték tízszeresét (azaz alapértelmezésben 20 megabájto0. El- 
lenkező esetben az SMTP kiszolgáló a postaláda telítésére hi- 
vatkozva visszautasítja a beérkező leveleket. 


A távoli tartományok beállításai 


A távoli tartományok tulajdonságlapja a fentieknél jóval bőbe- 
szédűbb: 


B Egy távoli tartomány tulajdonságlapja 


Az opciók a következők: 

A Allow incoming mail to be relayed to this domain: Az 
SMTP szolgáltatás elfogadja az ebbe a tartománya cím- 
zett bejövő leveleket és továbbítja azt a megfelelő ki- 
szolgálónak (azaz erre az egy tartományra nézve enge- 
délyezzük a Mail Relay-t) 

Send HELO instead of EHLO: ha bekapcsoljuk, az 
SMTP szolgáltatás a tartomány kiszolgálóival a kibőví- 
tett SMTP helyett az , eredeti" SMTP protokollt használ- 
ja (ez jóval kevesebb szolgáltatást biztosít) 

Outbound Security: A tartomány kiszolgálóihoz törté- 
nő kapcsolódás biztonsági beállításai (azonosítási mód 
[Anonymous/Basic/Windows Integrated], felhasználó- 
név, jelszó, TLS beállítások) 





FA Route domain: A levelek továbbításának 
módja, a szokásos DNS-alapú kiszolgálóke- 
reséssel (Use DNS to route this domain) vagy 
közvetlenül egy adott kiszolgálónak 
(Forward all mail to smart host). Ekkor meg 
kell adnunk a kiszolgáló DNS-nevét, vagy [IP-címét]. 


Ms 


Az SMTP szolgáltatás képes arra, hogy egy távoli tartományba 
címzett leveleket átmenetileg tároljon és ne próbálja meg azo- 
kat azonnal továbbítani. Erre akkor lehet szükség, ha a távoli 
tartomány SMTP kiszolgálója nem rendelkezik állandó 
internetes kapcsolattal. Amikor a távoli kiszolgáló bejelentke- 
zik a hálózatba, az SMTP protokoll ATRN parancsa segítségé- 
vel utasíthatja a kiszolgálónkat az addig gyűjtögetett és tárolt 
levelek továbbítására (természetesen az előbb tárgyalt Route 
domain mező beállításainak értelmében). 


2] 


CSS aes 





General. Advanced ) 


You can specify which accounts are authorized to use ATRN: 


[7 0ueue messages for remote triggered delivery 
SAccounts authorized to use ATRN: 
€$ FALATRAXZOOZVA dministrator 








Hemove I 
I Az ATRN opció beállítása 


Ehhez a távoli tartomány tulajdonságlapjának Advanced olda- 
lán kapcsoljuk be a Oueue messages for remote triggered 
delivery opciót, majd adjunk meg egy felhasználót. A távoli 
kiszolgáló ezzel a felhasználónévvel és természetesen a hoz- 
zá tartozó jelszóval kezdeményezheti az üzenetküldést. 


Joker-karakter a távoli tartomány nevében 


Ha akarjuk, a távoli tartomány nevében használhatjuk a " 
(csillag) karaktert. Az SMTP kiszolgáló ekkor a tartomány és 
minden altartománya esetén a beállításoknak megfelelően fog 
eljárni: 





A következő számban a POP3 szolgáltatás bemutatásával... 


. .. folytatjuk! 


Fülöp Miklós 
mick€inetcom.hu 


I 
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- Vége az erőforrásokért folyó versengésnek! / 


A Windows System Resource Manager 
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ht 


5. 
flanager 


A Windows sustem ResOurCce 


. Vége az erőforrásokért folyó 


versengésnek! 


A Windows System Resource Manager a folyamatok prioritását dinamikusan változtató algoritmus se- 
gítségével képes arra, hogy azok erőforrás-felhasználását az előre beállított határértékek alatt tartsa, így 


biztosítva az erőforrások optimális kihasználtságát. 


Ha több alkalmazást futtatunk egy kiszolgálón, megindul a 
versengés a rendszererőforrásokhoz való hozzáférésért. Ha a 
rendszer nem képes arra, hogy megvalósítsa az erőforrások 
optimális elosztását, vagy az erőforrások kihasználtsága nem 
lesz megfelelő, vagy a szűkös erőforrások a rendszer egészé- 
nek teljesítményét fogják csökkenteni. Hogy elkerülhessük a 
versengést, és a valós igények szerint oszthassuk meg az erő- 
forrásokat, erőforrás-felügyeleti szoftvert kell használnunk. 
Az erőforrás-felügyeleti szoftverek használatával növelhető a 
kiszolgálók kihasználtsága (a teljesítmény csökkenése nélkül), 
mivel segítségükkel a rendszergazdák meghatározhatják, hogy 
az egyes alkalmazások, folyamatok, vagy szolgáltatások mi- 
lyen mértékben használhatják a rendszer erőforrásait. Például, 
ha két CPU-igényes alkalmazást futtatunk párhuzamosan, elő- 
fordulhat, hogy egyikük az igényeihez képest aránytalanul ke- 
vés CPU időhöz jut. Az erőforrásfelügyelet megoldást nyújt az 
ilyenfajta problémákra. 

A Microsoft új erőforrás-felügyeleti eszköze a Microsoft Win- 
dows System Resource Manager (WSRM), amely a Windows 
Server 2003 Enterprise és Datacenter változatainak része, és 
csak ezekben használható. Az operációs rendszer telepítése 
után azonban hiába keressük a WSRM bármiféle nyomát, az 
eszközt a csomagban kapott külön CD-ről utólag kell telepí- 
teni. A telepítőt tartalmazó CD image az IWSRMI címről is 
letölthető. 


ETT áá ee] 
Installing or custornizing WSRM 
The items you selected are being applied. 





Please wait while the selections are applied... 
Statting services... 


Time remaining 2 seconds 





E A WSRM telepítése 


A Windows System Resource Manager 


A WSRM lehetővé teszi, hogy a rendszergazdák meghatároz- 
zák a CPU idő és a memória megosztását az egyes alkalmazá- 
sok, folyamatok és szolgáltatások között. Az eszköz lehetővé 
teszi a Microsoft Terminal Services-hez csatlakozó felhaszná- 
lók közötti erőforrás-megosztás felügyeletét is. A WSRM teljes 
funkcionalitása elérhető grafikus felületről (mmc snap-in) és 
parancssori interfész segítségével is. A parancssori interfész le- 
hetővé teszi szkriptek használatát is. 

A konzol indítására szolgáló parancsikont a felügyeleti eszkö- 
zök között találjuk, illetve használhatjuk a 


wsrm.msc 


parancsot is. 
A parancssori felületet a wsrmc.exe, és annak számtalan kap- 
csolója biztosítja. 










Microsoft? 
Windows System Resource Manager 








Current WSRM Status 










33 €gval Per User 
7 (7) Calendar lEratied 
TA Resource Montor 
B accowntna (Dsatted) 






WSRM management is currently RUNVING 
Click the status icon to change its settngs. 


A e s 


Calendar - Enabled management Type Current Resource 
Manage  Allocation Policy - 
WSRMDefault 
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Notification 
Disabled 














Accounting 
Disabled 


Windows System 
Resource Manager 
Help 





For context-sensítíve help through out WSRM, press F1. 
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E A Windows System Resource Manager grafikus felhasz- 
nálói felülete 


A CPU idő kiosztása 


A WSRM által felügyelt környezetben a folyamatok két cso- 
portba tartozhatnak: felügyelt és felügyelet nélküli folyama- 
tok. A felügyelet nélküli folyamatok (ezek tipikusan a rend- 
szerfolyamatok), nem tartoznak a WSRM hatáskörébe, ők ren- 
delkeznek a legmagasabb prioritással, annyi erőforráshoz jut- 


hatnak, amennyi csak rendelkezésre áll. A WSRM csak a felü- 
gyelet nélküli folyamatok által fel nem használt erőforrások fe- 
lett rendelkezik. Ez az oka annak, hogy a felügyelt folyamatok 
között az összes rendelkezésre állónál kevesebb erőforrást 
oszthatunk szét. 

A WSRM használatával a CPU idő elosztására alapvetően két 
módszer áll rendelkezésre. Egyrészt meghatározhatjuk, hogy a 
folyamat a rendelkezésre álló teljes CPU idő (az összes pro- 
cesszorra vonatkozóan) hány százalékát használhatja fel, 
másrészt megadható az is, hogy a folyamatok melyik pro- 
cesszoron (vagy processzorokon) futhatnak (processor 
affininty). 

A definiált korlátozások szigorúan érvényre jutnak, ha több fo- 
lyamat verseng a CPU időért, de ha másik folyamat nem 
igényli azt, ami járna neki, a felügyelt folyamat többet is fel- 
használhat a rendszergazda által meghatározott mennyiség- 
nél. Ez a rugalmasság különösen előnyös akkor, ha a rendszer- 
ben futó alkalmazások terhelése nem egyenletes. Ilyenkor az 
erőforrások elosztását az egyes alkalmazások átlagos terhelé- 
se alapján végezhetjük el, de az aktuálisan nagyobb terhelés- 
sel működő alkalmazás elveheti a többiektől az éppen nem 
használt erőforrásokat. Ilyen módon az erőforrások kihasz- 
náltsága folyamatosan optimális lehet. 


A memória kiosztása 


A WSRM lehetővé teszi, hogy a folyamatok memóriahaszná- 
latát két szempont szerint korlátozzuk: beállíthatjuk a folya- 
mat által felhasználható fizikai memória (working set), és a fo- 
lyamat számára kiosztott összes memória (committed 
memory) maximális mennyiségét. A working set a folyamat 
számára kiosztott virtuális lapok azon része, amelyek a fizikai 
memóriában helyezkednek el. Ha a folyamat memóriahasz- 
nálata eléri a beállított korlátot, a WSRM beavatkozik, és 
megakadályozza, hogy a folyamat további lapokhoz jusson a 
fizikai memóriában, illetve kezdeményezi a working set egy 
részének kilapozását. 

A committed memory a fizikai memóriának az a része, amely- 
nek a memóriakezelő lefoglalta a megfelelő helyet a háttértá- 
ron lévő lapozófájlban arra az esetre, ha a lapokat a lemezre 
kellene írnia. Memóriakezelési problémára (memóriaszivár- 
gás) utal, ha egy folyamat növekvő mértékben használ 
committed memóriát, ekkor valószínűleg nem szabadítja fel 
az előzőleg lefoglalt, de már nem használt lapokat. Ha a fo- 
lyamat memóriahasználata eléri a beállított értéket, a VVSRM 
választásunk szerint leállítja azt, illetve hibajelzést ír a rend- 
szernaplóba. 














b CPU idő felhasználás l 


Working set: 20MB 
Committed mem:8B0MB 


Working set: 20MB 
Committed mem: BOMB 


Memóriakiosztás 





1 Kiszolgáló 


E A WSRM az erőforráselosztási házirend beállításai 


alapján felügyeli az erőforrásokhoz való hozzáférést 





A WSRM felépítése 


A WSRM a rendszererőforrások felügyeletét a folya- 
matok prioritását dinamikusan változtató algoritmus 
segítségével végzi, amely meghatározza az erőforrá- 
sok elosztását a felügyelt folyamatok között. A 
WSRM meghatározott lekérdezési ciklus szerint ellenőrzi a 
felügyelet folyamatok által lefoglalt erőforrások mennyiségét. 
Minden lekérdezés alkalmával összehasonlítja az aktuális erő- 
forrás-felhasználást a beállított értékekkel. Ha egy folyamat túl 
sok erőforrást foglal, a VWSRM csökkenti annak prioritását. 
Minden folyamat egy vagy több végrehajtási szálból áll, ezek 
a folyamat végrehajtható komponensei. Mivel a szülőfolyamat 
prioritási szintje nagymértékben befolyásolja szálainak priori- 
tását, a folyamat prioritásának csökkentése a szálak prioritását 
is csökkenti. A Windows operációs rendszer prioritásos 
preemptív (round-robin) ütemezési rendszert használ, amely a 
szálakat prioritásuknak megfelelő sorrendben hajtja végre. 
Ilyen módon a folyamat prioritásának csökkentése, indirekt 
módon egyben az által felhasznált erőforrások mennyiségét is 
csökkenti. 

Az alkalmazások, folyamatok és szolgáltatások erőforrás-fel- 
használásának beállítását két lépésben kell elvégeznünk: 

A meghatározzuk a folyamatoknak azon csoportját, ame- 
lyekre a beállítandó szabály vonatkozni fog (process- 
matching criteria) 

HA az adott folyamatok számára meghatározzuk a felhasz- 
nálható erőforrások maximális mennyiségét (resource- 
allocation policies) 


- 


Parancssori interfész 
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Windows Server 2003, Erőforrás monitor 
Enterprise Edition 
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E A WSRM felépítése 


A felügyelt folyamatok kiválasztása 


A WSRM lehetőséget nyújt arra, hogy a felügyelni kívánt fo- 
Ilyamatokat csoportokba rendezzük, és a létrehozandó erőfor- 
rás-felhasználási szabályokat ezekhez a csoportokhoz rendel- 
jük hozzá. Ha a csoporthoz CPU korlátozást állítunk be, a 
WSRM egyenletesen osztja el a megadott CPU időt a csoport- 
hoz tartozó folyamatok között. Azonban ha memóriahaszná- 
latra vonatkozó korlátozást adunk meg, a korlát minden egyes 
folyamatra külön-külön értelmezendő. A csoporthoz tartozó 
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folyamatok kiválasztására szolgáló szempontokat 
(process-matching criteria) az mmc konzol felületén 
és parancssorból is megadhatjuk. A WSRM a folya- 
matok következő három tulajdonságát hasonlítja 
össze a beállított értékekkel: 
TA a folyamatot létrehozó alkalmazás végrehajtható fájljá- 
nak teljes útvonala, illetve annak bármilyen része. 
TA a folyamat létrehozásának és elindításának pillanatá- 
ban átvett parancssori sztring bármilyen része. 
TA a folyamatot elindító felhasználó, vagy felhasználói 
csoport. 
Minden olyan folyamat, amely egyetlen beállított érték szerint 
sem azonosítható, az alapértelmezett csoport (default group) 
tagja lesz. 
A fájlnév, illetve útvonal megadásakor helyettesítő karaktere- 
ket is használhatunk, ha egyszerre több alkalmazást is szeret- 
nénk kiválasztani. 
Például a 


CEN 


megadása az összes olyan folyamatot kijelöli, aminek teljes 
útvonalában a "c:Mprogram files" sztring előfordul. 


New Process Matching Criteria 


Add, edit or remove rules to match the running processes. 








Criteria name: 


Programok 


Rules: 
Files or Command Lines 


tejel 


Users or Groups 





5 A csoporthoz tartozó programok kiválasztása 


A kritikus rendszerfolyamatok alapértelmezés szerint felügye- 
let nélküliek, így ezek bármennyit felhasználhatnak a rendel- 
kezésre álló rendszererőforrásokból. Ennek megvalósítása ki- 
vétellisták (exclusion lists) segítségével történik, az ezeken 
szereplő folyamatok mindegyike felügyelet nélküli. Két kivé- 
tellistánk is van, mindkettő tartalma megtekinthető, ha a kon- 
zolfában megnyitjuk a Windows System Resource Manager 
tulajdonságlapját. A rendszer által meghatározott (system- 
defined) lista tartalma nem módosítható, ezen szerepelnek a 
legfontosabb rendszerfolyamatok. A felhasználó által megha- 
tározott (user-defined) listát azonban tetszés szerint bővíthet- 
jük, illetve szűkíthetjük. A kivétellistákon szereplő valamennyi 
folyamat felügyelet nélküli lesz. 


Az erőforrás-elosztási házirendek 


A felügyelt folyamatokhoz az erőforrás-elosztási házirendek 
(resource-allocation policies) segítségével rendelhetjük hozzá 
a nekik szánt erőforrásokat. Minden erőforrás-elosztási házi- 
rend egy vagy több folyamatcsoportot tartalmaz, amelyekre 
vonatkozóan megadhatjuk a kívánt CPU felhasználási szintet, 
a memóriára vonatkozó korlátozásokat és a processzoraffini- 
tással kapcsolatos adatokat. 


Az alábbi ábrán látható, hogy a létrehozandó erőforrás- elosz- 
tási házirendhez hozzárendeljük a korábban létrehozott cso- 
portot (amely a c: program files mappában lévő összes progra- 
mot tartalmazza) és nekiadjuk a processzoridő 50 százalékát. 












New Resource állocation Policy 


Create a resource allocation policy by specifying a policy name. 
You can allocate processor and memory resources to each 
process matching criteria. 


Policy name: 
I Programok 
Allocate these resources: 


Process Matching Criteria 
Programok 






Processors 








Bemove I 


Available percentage of processor remaining: 50 


OK ! Cancel l 


E Erőforráselosztási házirend létrehozása 


Miután elvégeztük a csoport és a korlátozások összerendelé- 
sét, a WSRM figyelni kezdi a csoporthoz tartozó folyamatok 
erőforrás-felhasználását. Ha a CPU használat meghaladja a 
beállított értéket, a WSRM csökkenti a folyamatok prioritását, 
így a Windows ütemezőjétől az kevesebb processzoridőt fog 
kapni. Korábban már említettük, és az alábbi ábrán is látható 
(1), hogy a CPU idővel ellentétben a felhasználható memória 
korlátozása a csoport minden egyes folyamatára külön-külön 
értendő. 


Add or Edit Resource Allocation M- 


General. Memory ] Advanced] 


212 


Specify the committed memory and working set limits for this 
resource. 


[7 Use maximum committed memory for each process 
Maximum committed memory limit per 


process (in MB): [80 
If memory is surpassed: [stop the application r] 


telle ella -gk- ej e] lSzzAt Tea] 





[I Use maximum working set limit for each process 


—— 


Maximum working set limit per process 
(in MB 





E A memória kiosztása 





Minden erőforráselosztási házirendhez automatikusan létre- 
jön egy alapértelmezett csoport (default group), amely tartal- 
mazza az összes olyan folyamatot, amelyek nem feleltek meg 
egyetlen kiválasztási feltételnek, és nem szerepelnek a kivétel- 
listákon sem. Az alapértelmezett csoport tagjai egyenlően osz- 
toznak azokon az erőforrásokon, amelyeket a felügyelet nél- 
küli és a felügyelt folyamatok még nem használtak fel. 


A WSRM Calendar 


A szolgáltatás lehetővé teszi az erőforrás-elosztási házirendek 
előre megadott időzítés szerinti, automatikus aktiválását. Erre 
akkor van szükség, ha a felügyelt alkalmazások terhelése, és 
ezzel párhuzamosan erőforrásigénye egy adott időszak alatt 
szisztematikusan változik. 

A szolgáltatás segítségével három különböző időzítéstípus 
hozható létre: 


H egyszeri esemény (OneTime Event) 

TH rendszeres esemény (Recurring Event) 

A napi időrend (24 órás periódus alatt beállítható több 
erőforrás-elosztási házirend aktiválása, majd a napi 
időrend hozzárendelhető a megfelelő naptári napok- 
hoz, Schedule) 


A teljesítményadatok vizsgálata a Resource Monitor segít- 
ségével 
A Resource Monitor GUI segítségével megtekinthetjük a helyi 
gép, illetve távoli számítógépek real-time teljesítményadatait. 
A Resource Monitor szabványos Windows rendszermonitor 
(PerfMon), amelyhez három új teljesítményszámláló tartozik: 

TH WSRM: Policy 

IA WSRM: Process 

I WSRM: Process Matching Criteria 


A Resource Monitor által megjelenített adatokat a következő 
paraméterek megadásával definiálhatjuk: 

TA Az adatok típusa. Meg kell határoznunk az objektumot 
(például folyamatok, vagy processzor) és ki kell vá- 
lasztanunk az objektumhoz tartozó teljesítményszám- 
lálók közül a megfelelőt (például working set mérete, 
vagy 96 Processor time). 

A Az adatok forrása. A Resource Monitor képes a helyi 
gépen kívül, a hálózatban elérhető számítógépek ada- 
tainak megjelenítésére is. Az adatok lekérdezéséhez 
alapértelmezés szerint rendszergazdai jogosultság 
szükséges. Megjeleníthetők továbbá a korábban szám- 
lálónaplókba (counter logs) gyűjtött adatok is. 

TH Mintavételi paraméterek. A Resource Monitor támo- 
gatja az igény szerinti manuális, és a megadott időkö- 
zönkénti automatikus mintavételezést is a real-time 
adatok esetében. A tárolt adatok megjelenítésekor a 
kezdő és befejező időpontot adhatjuk meg, így megje- 
leníthetők a vizsgált időszak adatai. 
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5 A Resource Monitor 


A WSRM accounting 


A szolgáltatás segítségével eltárolhatjuk és visszatölthetjük a 
felügyelt folyamatok viselkedésével kapcsolatos adatokat. Az 
adatokat felhasználhatjuk jelentések készítéséhez, és a felü- 
gyelt folyamatok erőforrás felhasználással kapcsolatos viselke- 
désének tanulmányozásához. 




















User [ot Name 
TNTRAS, Adm WSAMDSfUK 
MT ALT... 95... WSRMDefauk 
NITRA.. hám. WSRMefaut 
NTAUT.., SY5...  WSRMDEfaut 
ANTRA... Adm... WSAMDSf au 
NT ALT... VS... WSRMDEfout 
NT ALT... SS... WSAMDetat 
NTRA..  Admb. WSAMDefauk — 6/26/20037-3. 

NT ALT... SS... WSAMDEtat — 6/26/20097:5... . Defaut 426 














fedtcpsves ere 
jedvtmareser,.. NT AUT,.. SV5...  WSRMDEfoR — E/26(20037:3...  Defőut 6/z6 
jevtásaretró,.. INTRA... Adm... WSRMDEfadt  6/26/20037:3...  Defaut 6/26 
jefovrmssrelse... INTRA... Adm... WSAMDefadt  É/26/20007:3...  Defadt 6/26 
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E A WSRM accounting 


A kiszolgálók kihasználtságának növekedése 


Ha több alkalmazást futtatunk egy kiszolgálón, a WSRM hasz- 
nálatával jelentősen növekedhet a kiszolgáló kihasználtsága, 
mivel segítségével a rendszergazdák kontrollálhatják az egyes 
alkalmazások, folyamatok, és szolgáltatások által felhasznált 
erőforrások mennyiségét. Ilyen módon megelőzhető az erő- 
forrásokért való versengés, és optimalizálható a szűkös erőfor- 
rások elosztása és kihasználtsága. 
Szerényi László 
szerenyi.lomet.hu 
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Pack] 


Új téglák a (tűz)falban 


[DR Server 1000, Feature 


A nemrégiben megjelent ISA Server 2000 Feature Pack 1 segítségével tűzfalunk funkciói kiteljesednek 
(kiterjedt SMTP-filter, URLScan 2.5 stb.), néhány mindennapos feladat megoldása sokkal egyszerűbbé 
válik (például az OWA kiszolgálóik publikálása). És ez még nem minden! 


Áttekintés 


A Microsoft Internet Security and Acceleration Server 2000 
Feature Pack 1 a szokványos tűzfalaknál nagyobb biztonságot 
nyújt a Microsoft Exchange és IIS kiszolgálók üzemeltetői szá- 
mára. A vállalatok egyre nagyobb mértékben használják üzle- 
ti folyamataikban az e-mailt és a Web lehetőségeit, így egyre 
nagyobb igény mutatkozik részükről az e-mail és Web kiszol- 
gálók fokozottabb védelmére. Az ISA 2000 Feature Pack 1 se- 
gítségével a nagyobb biztonság egyszerűbb használattal és 
felügyelettel párosul. 
Az ISA Server 2000 Feature Pack 1 a következő fejlesztéseket 
tartalmazza: 

HA Továbbfejlesztett SMTP szűrő. 

H Továbbfejlesztett Exchange távoli eljáráshívás (RPC) 
szűrő. 
URLScan 2.5 for ISA Server 
RSA SecurelD hitelesítés használata 
A hagyományos és a SecurelD hitelesítés delegálása 
Outlook Web Access Wizard 
RPC Filter Configuration Wizard 
Link Translator 
A felhasználással és hibaelhárítással kapcsolatos doku- 
mentáció. 


BEBBBBB 


A továbbiakban részletesen áttekintjük az említett új lehetősé- 
geket, amelyek segítségével védettebbé tehetők az e-mail, 
Web, és OWA kiszolgálók, és egyszerűbbé válhat a rendszer- 
felügyelet. Az ISA Server 2000 Feature Pack 1 az [ISAFP] cím- 
ről tölthető le. 


Az e-mail kiszolgálók védelme 


Az ISA Server 2000 Feature Pack 1 a következő szolgáltatások 
segítségével fokozza az e-mail kiszolgálók biztonsági szintjét: 
TA Az SMTP szűrő továbbfejlesztett változata nagyobb vé- 
delmet nyújt a nem kívánt e-mail üzenetekkel szem- 
ben. 
A VPN nélkül is védelmet biztosít a távoli Outlook klien- 
sek számára. 


Az ISA kiszolgáló alkalmazásszintű szűrés segítségével terem- 
ti meg az e-mail kiszolgálók biztonságát. Az e-mail forgalom 
folyamatos figyelése csökkenti annak esélyét, hogy vírusok és 
nem kívánt üzenetek kerüljenek be a vállalati hálózatba. 

Az SMTP szűrő feladata az, hogy megvizsgálja a 25-ös portra 
érkező teljes forgalmat. A szűrő fogadja és feldolgozza az üze- 


neteket, és a beállított szabályoknak megfelelően továbbítja, 
illetve blokkolja azokat. A szűrés történhet a mellékletek ne- 
ve, kiterjesztése és mérete alapján, valamint a feladó, a 
domain, bármely kulcsszó, vagy SMTP parancs, illetve annak 
hossza szerint is. 

Az üzenetek szűrését két különállóan implementált kompo- 
nens valósítja meg: 

HA Az SMTP szűrő az engedélyezett, illetve tiltott SMTP 
parancsok szűrését valósítja meg, az üzenetek tartal- 
mával NEM foglalkozik. Az SMTP szűrő alapértelme- 
zés szerint fel van telepítve, de működését külön enge- 
délyeznünk kell. 

A Az üzenetfigyelő (message screener) az Exchange 2000 
SMTP kiszolgálójának egyik kiterjesztése, amely opcio- 
nálisan telepíthető. Az ISA kiszolgáló telepítése közben 
csak akkor kérhetjük az üzenetfigyelő telepítését, ha az 
SMTP kiszolgáló már telepítve van a számítógépen. Az 
üzenetfigyelő feladata az üzenetek tartalmának szűrése 
a megadott kulcsszavak, melléklet-típusok, és feladók 
szerint. Az SMTP szűrő az üzenetfigyelő nélkül is tele- 
píthető, de ebben az esetben csak az SMTP parancsok 
szűrésére van lehetőség. Az üzenetfigyelő beállításait 
az SMTP szűrő tulajdonságlapján adhatjuk meg. 


SMTP Filter Properties § SZET] 
General] Altachments ] Users / Domans ] Keymords SMTP Commands ] 

















(Enatle — ! Commands 

o BDAT 20 

o DATA 6 

e SMTP Command Rule [2 
o [7 Enable an SMTP command 

ő álkésrki Né MAJLFROM 

e 

e fee 

e Marámur Length : Bytes 

o 





nm 


Az SMTP szűrő képes (sok egyéb mellett) bármely 
SMTP parancs hosszát is figyelembe véve válogatni a 
levelek között 


Az ISA kiszolgáló lehetővé teszi, hogy az Outlook kliensek és 
az Exchange kiszolgálók közötti e-mail forgalom megbízhatat- 
lan hálózatokon keresztül is VPN használata nélkül bonyolód- 
hasson. Ezt a képességet fejleszti tovább a Feature Pack 1 a 
következő tulajdonságok segítségével: 


Kötelező RPC titkosítás 

Az ISA 2000 Feature Pack 1 lehetővé teszi, hogy a rendszer- 
gazdák kötelezővé tegyék a távoli eljáráshívással (RPC) kap- 
csolatos kommunikáció titkosítását az Outlook kliensek és az 
Exchange kiszolgálók között. Így VPN kapcsolat nélkül is foly- 
hat titkosított kommunikáció. 


Exchange Server 











ISA kiszolgáló 
ses ái sé elet] 





Titkosított RPC 





3 Titkosított RPC az Outlook kliensek és az Exchange ki- 
szolgáló között 


Kimenő RPC kommunikáció engedélyezése 

Az ISA 2000 Feature Pack 1 lehetővé teszi, hogy az ISA által 
védett Outlook kliensek RPC kommunikációt folytassanak a 
tűzfalon kívül elhelyezkedő Exchange kiszolgálókkal. 


Exchange Server 


ISA kiszolgáló 
4 Feature Pack1 





Titkosított RPC 


E A Feature Pack 1 lehetővé teszi a kimenő RPC kommu- 
nikációt 


A Web és OWA kiszolgálók védelme 


Az ISA 2000 Feature Pack 1 a következő fejlesztések segítsé- 
gével fokozza a Web és OWA kiszolgálók biztonságát: 
HA Védelmet nyújt az Interneten lévő kiszolgálók elleni tá- 
madások legújabb típusaival szemben is. 
A Az hitelesítés új módszereinek segítségével a hozzáfé- 
rés jobban kézbentartható. 


Az alkalmazások egyre nagyobb része használja kommuniká- 
ciós célra a HTTP és a HTTPS protokollokat, így egyre több, 
ezeken a protokollokon utazó féreg és vírus támadja meg a 
vállalati hálózatokat. Sajnos a hagyományos csomagszűrő 
tűzfalak képtelenek feltartóztatni az ilyen típusú támadásokat, 
ehhez az alkalmazási rétegben működő tűzfalra van szükség. 
Az ISA Server 2000 és a Feature Pack 1 megkönnyíti a bizton- 
sági beállítások felügyeletét, és segítségükkel a kártékony Web 
kérések már a tűzfal számítógépen blokkolhatók, így nem jut- 
hatnak be a vállalat hálózatába. 


technet vér kin ag w i 


URLScan 2.5 for ISA Server 


A webalapú támadások általában szokatlan kérése- 
ket tartalmaznak, hosszú karakterláncokból állnak, 
vagy különleges karakterkészlet szerint vannak kó- 
dolva. Az URLScan teszi lehetővé, hogy az ISA ki- 
szolgálók észleljék és elhárítsák az ilyen típusú támadásokat. 
Ha az URLScan nem minden egyes web és OWA kiszolgálón, 
hanem csak a védelmüket ellátó ISA kiszolgálón működik, a 
rendszer komplexitása, és a felügyelet munkaigénye is jelen- 
tősen csökkenthető. 


ISA kiszolgáló 
4 Feature Pack1 





"web-alapú tárnadások 


E Az IIS és OWA kiszolgálókat a tűzfalon futó URLScan 
védi 


RSA SecurID hitelesítés 


Az RSA SecurelD hitelesítés segítségével korlátozható a Web 
és OWA kiszolgálók felé irányuló forgalom; a vállalat hálózat- 
ba csak érvényes kérések juthatnak be. 


Meya ea láza [2Tx] 
General] Destinations — ] 0 Acton — ] —— Bridong 1 
Applies To l Link Translation RSA SecuiD 


Ez Enable RSA web Access Authentication Feature 5 

(77 Cookie Expiration Control —— E te 
C Cookies Expire If Not LIsed Within the Specified Time ! 
6  Cookies Always Expire After the Specified Time ] 
Expíration Time: [15 Minutes 

- Advanced Setltings 
[7 Prevent Caching of Protected Pages on Clients 
TT Ignore Browser IP Address for Cookie Validation 
[7 Use RSA ACE/Server 5.0 Name Locking Feature 
[7 Use Separate User Name and PASSCODE Pages 





Manage Domain Configuration j 











Authentication for RSA SecurlD based on technology Írom RSA Security Inc. 








[dok ] cmea [7 árow ] 


E A SecurlID hitelesítés engedélyezése az ISA kiszolgálón 


Ha a felhasználó SecurID-vel védett weblapok elérését kezde- 
ményezi, az ISA Servert futtató kiszolgáló (a védett kiszolgáló 
nevében) bekéri a felhasználó nevét és PASSCODE-ját. Az ISA 
kiszolgálón futó RSA ACE/Agent továbbadja az adatokat az 
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RSA ACE/Server-nek. Ha az azonosítás sikeresen 
megtörtént, a felhasználó böngészője egy cookie 
formájában megkapja a felhatalmazást, hogy az 
adott munkamenet tartama alatt a védett tartalom- 
hoz hozzáférjen. 

Az RSA SecurID hitelesítés használatának beállítása a követ- 
kező lépésekből áll: 


TA Az RSA ACE/Serveren az ISA kiszolgáló megadása, 
mint RSA ACE/Agént 

A A felhasználók hozzáadása az RSA ACE/ Agent Host 

recordhoz 

Az ACE/Serverrel való kapcsolat tesztelése 

Webpublikálási szabály létrehozása 

Az ügyfél és az ISA kiszolgáló közötti biztonságos kap- 

csolat beállítása. 


BBB 


A hagyományos és a SecurID hitelesítés delegálása 


A Feature Pack 1 segítségével lehetővé válik az is, hogy az 
RSA SecurID alapú, illetve a hagyományos hitelesítést is az 
ISA kiszolgáló végezze el a Web és OWA kiszolgálók számá- 
ra. A védett kiszolgálók az ISA Server-re bízzák az ügyfelek hi- 
telesítését, így nincsen szükség arra, hogy a felhasználók több- 
ször megadják hitelesítési adataikat. A delegáció minden 
egyes Web publikálási szabály esetében külön engedélyezhe- 
tő, illetve tiltható. 


Könnyebb használat és rendszerfelügyelet 


Az ISA Feature Pack 1 a következő eszközöket biztosítja a 
rendszergazdák számára: 


1 Könnyen használható varázslók teszik egyszerűbbé a 
hálózat védelmét. 

HR A vállalati intraneten lévő információk könnyen közzé- 
tehetők az Interneten. 

IA A dokumentációban a gyakoribb kérdésekre gyorsan 
választ találhatnak. 


OWA varázsló 
Az OWA varázsló a következő szolgáltatásokat biztosítja: 

IA Automatikusan generálja a megfelelő értékeket tartal- 
mazó Web publikációs szabályokat (Web publishing 
rule) és célcímkészleteket (destination set. 

"TA A megfelelő figyelőket hozzárendeli az ISA Server kül- 
ső címeihez. 


Kiválasztja a megfelelő tanúsítványt a Secure Socket Layer 
(SSL) kapcsolathoz. 





New OWA Publishing Wizard 


Name of Published Server 
Type the computer name of the Outlook web Access server that you want to 
publish. 





Intemal name orIP address of Dutlook Web Access Server 
JOwaA-01 Browse... 
TT Use an SSL connection from the ISA Server to the Outlook web Accesz Server 

The common name of the Outlook Web Access SSL certificate must match the name of 





E Az OWA kiszolgálók védelmének gyors és egyszerű 
beállítása az ISA-n 


RPC Filter Configuration Wizard 


Az ISA Serveren eddig az RPC szolgáltatásokhoz való hozzá- 
férést csak mindent vagy semmit alapon tudtuk befolyásolni. 
Az ISA 2000 Feature Pack 1 azonban lehetővé teszi, hogy 
meghatározzuk az egyes RPC szolgáltatásokhoz való hozzáfé- 
rés lehetőségét is. Választhatunk a varázsló által megjelenített 
listából, illetve magunk is összeválogathatjuk az RPC inter- 
fészt. A szolgáltatásdefiníciókat a publikálási szabályban is 
felhasználhatjuk, így a külső ügyfelek is elérhetik azokat. 


Server Interfaces té b 
These are the RPC interfaces (UUID5) avalable on this computer. segőz 





Select the RPC interfaces you want to include in the RPC protocol definition: 


Computer name: EXCH.02 













E 199264010-b032-11d0-97a4-O0-O4fd6551d). Exchange Server STORE ADM 

[TI (3e8e€830-4459-11ce-379b-0032005Ifebe) MS Exchange MTA Mta! Interfz 

EZ (a4ftdb00-ca47-1067-bö1e-OOddOT10662dal Exchange Server STORE ADM 

EZ fasftdb00-ca47-1067-b31(-O0OddO10662da) Exchange Server STORE EMS 

(CD (a520d06e-11de-11d2-ab59-00c041a3590c) 

[T (btag51d1-2f0e-11d3-btdt-00c041a3490a1 

CD (főcc5a18-4264-101a-8c59-OSOOZb2IB426) MS Exchange Directory NSPI FT. . 
, 





3 A belső RPC szolgáltatásokhoz való hozzáférés finom- 
hangolása az RPC varázsló segítségével. 


Link Translator 


Az ISA Server Feature Pack 1-ben mutatkozik be a Link 
Translator, amely lehetővé teszi az abszolút hivatkozásokat 
tartalmazó webhelyek publikálását. A link translation segítsé- 
gével az abszolút hivatkozásokat tartalmazó webhelyeket a 
külső felhasználók is hibás linkektől mentesen érhetik el. Az 
Internet felől érkező böngészők számára a Link Translator az 
ilyen hivatkozásokat átalakítja a megfelelő webes hivatkozá- 
sokká. A szolgáltatás használatával nincsen szükség az 


intranet oldalak módosítására, hogy a külső felhasználók szá- 
mára is elérhetővé váljanak. 


Az ábrán látható példa bemutatja a Link Translator műkö- 
dését: 












Internet lap 
ca hrefznttp./www.minta.hu"z 


iSZag-sz 
ez ülsz 





H Az Internetről érkező ügyfél lekéri a www.minta.hu 
webkiszolgálón található lapot. 

m A kiszolgáló által tárolt lap abszolút hivatkozást tartal- 
maz a minta.hu intranetes számítógépére (http://minta). 
A Link Translator használata nélkül a felhasználóhoz 
érkező lap a működésképtelen intranet címeket tartal- 
mazná. A problémát csak az összes hivatkozás manuá- 
lis módosításával oldhatnánk meg. 

IH Amikor a lap áthalad az ISA kiszolgálón működő Link 
Translatoron, az összes intranetes hivatkozás (http:// 
minta) Internet címmé módosul (http:/Awww.minta.hu). 

HA A felhasználó által kapott oldalon az összes hivatkozás 
megfelelően működik. 


A Link Translator a hivatkozások módosítását az 
alapértelmezett hivatkozás-fordítási szótár (link translation 
dictionary) segítségével végzi, amely létrejön minden Web 
publikálási szabályhoz, amelyen a hivatkozások fordítását en- 
gedélyezzük. A hivatkozás-fordítási szótár az igényeknek 
megfelelően bővíthető. 

A Link Translator a következők szerint végzi a szótárban való 
keresést: 


A Először a leghosszabb keresési sztring, majd csökkenő 
sorrendben a többi, végül az alapértelmezett sztringek. 

H Találat esetén a szűrő megvizsgálja a sztringet követő 
karaktert 

HA Ha a karakter termináló karakter, a szűrő elvégzi a 
megadott helyettesítést. A termináló karakterek teljes 
listája az ISA Server Feature Pack 1 on-line súgójában 
található. 





Tekintsük át az előző példa szerinti helyzetben a 
beállítás szükséges lépéseit. 


A helyzet tehát a következő: 

A belső webhelyet, amelynek NetBIOS neve "Minta" 
publikáljuk az Interneten http://www.minta.hu néven. A 
webhelyen a Web kiszolgáló NetBIOS nevét tartalmazó hivat- 
kozások is vannak. Olyan linkek is lehetnek a webhelyen, 
amelyek a belső hálózaton lévő (kívülről el nem érhető) Web 
kiszolgálók NetBIOS neveit tartalmazzák. 


FA Engedélyezzük a Link Translator Web szűrőt. 

FA Létrehozzuk a www.minta.hu-t tartalmazó célcímkész- 
letet. 

ma A kiszolgáló publikálásához létrehozzuk a megfelelő 
Web publikálási szabályt. 

A A publikálási szabályhoz létrehozzuk a megfelelő hi- 
vatkozás-fordítási szótárt. 


A Link Translator segítségével módosított hivatkozások (ame- 
lyek a belső hálózatba mutatnak) potenciálisan biztonsági 
kockázatot jelentenek. A kockázat csökkentése érdekében 
gondosan kell definiálnunk az ISA kiszolgáló célcímkészleteit 
és webpublikálási szabályait. 


A felhasználással és hibaelhárítással kapcsolatos dokumen- 


táció 


Forgatókönyvek és technikai dokumentáció könnyíti meg a 
rendszer megfelelő beállítását, segítségükkel az Exchange és 
IIS telepítések gyorsan és könnyen elvégezhetők. A Feature 
Pack 1-hez tartozó dokumentációból minden szokásos kér- 
désre választ kaphatunk. A dokumentáció a következő eleme- 
ket tartalmazza: 


A Az ISA 2000 Server Feature Pack 1 dokumentációja. 

HA Webpublikálással kapcsolatos dokumentáció. 

HA Az Exchange kiszolgálók publikálásával kapcsolatos 
dokumentáció. 


Szerényi László 
szerenyi.Iomet.hu 
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" Ruagy a bürokrácia diszkrét bája 


Biztonságos aláírás kezelő alkalmazás készítése 


ÚR 


Biztonságos aláírás kezelő 
alkalmazás készítése III. 


Avagy a bürokrácia diszkrét bája 


Az ember minden épeszű mértéken áthágva képes elbonyolítani tulajdon életét. Ez különösen igaz tár- 
sadalmi méretekben, pláne ha az adminisztráció oldaláról közelítjük meg a jelenséget. Az elektroni- 
kus dokumentumkezelés és aláírás sajnos ezen mit sem javít: csak a hagyományos papír alapú admi- 
nisztrációt képzi le elektronikus formára. A kommunikáció felgyorsulhat és egyszerűsödhet, de a folya- 
matok alapvetően nem változnak. Mivel az aláírás (akár a hagyományos, akár az elektronikus) egy jo- 
gi szempontból is érvényes kötelezettségvállalást fejezhet ki, duplán igaz rá minden bürokratikus sza- 
bály. Nem az elektronikus aláírás bonyolult, hanem az élet, aminek próbál megfelelni. 


Kötelezettségvállalások 


Az előző fejezetben többször volt hivatkozás ún. kötelezett- 
ségvállalási típusokra minden magyarázat nélkül. Bizonyára 
többen is majd lerágták a körmüket izgalmukban, hogy mi is 
ez az igen érdekfeszítően hangzó dolog. De, ahogy a filmso- 
rozatok is a legizgalmasabb résznél szakadnak meg két rész 
között, nálunk is itt jött az oldal vége. 

A jobb megértés végett a hagyományos aláírás analógiája 
mentén kezdenék: egy aláírással sok mindent kifejezhetünk. 
Ugyanaz az aláírásunk mást és mást jelenthet a körülmények- 
től és szándékunktól függően, mely jobb esetben kiderül a 
(szöveghkörnyezetből, rosszabb esetben nem. Például egy vál- 
lalkozási szerződésen szerepelhet a megrendelő beszerzési 
igazgatójának és jogi osztályvezetőjének, s a beszállító két 
ügyvezetőjének és jogászának aláírása (lásd aláírói szerepkö- 
rök). Egy ingatlan adásvételen a vevő és eladó, valamint az el- 
lenjegyző ügyvéd aláírása, egy ingójelzálog bejegyzési okira- 
ton a zálogba adóé és a közjegyzőé. Egy házassági szerződé- 
sen a férjjelölt és feleségjelölt, egy kölcsönszerződésen a köl- 
csönbeadó és vevő, valamint a két tanú aláírása. Mindegyik 
esetben a szerepekből adódóan is más-más kötelezettségvál- 
lalás történik. Némelyik egyértelmű a szerződés szövegéből, 
némelyik nem (pl. tanúk szerepe). 

De az is lehet, hogy nem szerződésről, hanem egy megrende- 
lésről, egy visszaigazolásról, egy ajánlatkérésről vagy ajánlat- 
ról, vagy csak egy sima érdeklődésről van szó abban a levél- 
ben, mely aláírásra kerül. Ez esetben a kötelezettségvállalás tí- 
pusa máris kevésbé egyértelmű. Különösen, ha nagy szerveze- 
tekről van szó, és sokszereplős ügyletekről. Ki tudja, ki, mikor, 
mire vállalhat egyáltalán kötelezettséget. Ugyanaz a személy 
ugyanazon aláírása az egyik alkalommal kifejezhet egy teljes 
körű kötelezettségvállalást, máskor meg csak egy szimpla lát- 
tamozást. Papír esetében például attól, hogy az egyik a lap 
jobb alsó sarkában van apróban, a másik meg egy vonal és 
megrendelő felirat felett nagy méretben. Elektronikus doku- 
mentumoknál az ilyen bevett trükkökre nincs mód, s nem is 
biztos, hogy ez lenne az üdvözítő. 

A megoldás az, hogy az adott környezetre (melyre az aláírá- 
si szabályzat vonatkozik), az aláírás ellenőrzési szabályzat az 
összes szóba jöhető kötelezettségvállalási típust definiálja. 
Ezek közül az aláírás megtételekor vagy azt megelőzően 


az aláíró választhat, mely ezáltal az aláírás részévé válik. 
Az aláírás ellenőrzőjének a kötelezettségvállalás típusát 
(csakúgy, mint az aláírási szabályzat egyéb paramétereit) 
egyértelműen fel kell ismerni, s jelentésével tisztában kell 
lenni. 

Egy kötelezettségvállalás meghatározása egy egyedi objek- 
tumazonosítóból (OID) és egy minősítésből áll. A minősítés a 
kötelezettségvállalás bővebb (pl. szöveges) leírását tartalmaz- 
Za. A kötelezettségvállalás típusa definiálva lehet az aláírási 
szabályzaton belül is, de meghatározhatja egy külső (az aláí- 
rási szabályzat által elismert) környezet is. Így meghatározhat- 
ja jogszabály, szabvány, szerződés, egyéb alkalmazási kör- 
nyezet-jellemző, valamint valamilyen definíciós tár is. 

A letagadhatatlanság kezelésére például a következő típusú 
kötelezettségvállalások szolgálhatnak: 


Az aláíró készítette az üzene- 
tet (de nem feltétlenül hagyta 
jóvá és küldte el azt). 

A Jóváhagyás igazolása: Az aláíró jóváhagyta az üze- 

netet (de nem feltétlenül küld- 

te el azt. 

Az aláíró küldte el az üzenetet 

(de nem feltétlenül ő készítet- 

te és hagyta jóvá). 

A Származás igazolása: Az aláíró elismeri, hogy ő ké- 
szítette, hagyta jóvá és küldte 
az üzenetet. 

A Kézbesítés igazolása: A szolgáltató jelzi, hogy az 

üzenetet egy a címzett által 

hozzáférhető lokális tárolóba 

(tipikusan annak postaládájá- 

ba) eljuttatta. 

Az aláíró elismeri, hogy átvet- 

te az üzenetet. 


A Előállítás igazolása: 


A Küldés igazolása: 


A Átvétel igazolása: 


Ezek a kötelezettségvállalások egymásra épülnek (egyre ma- 
gasabb bizonyosságot jelentenek). 

E mellett definiálni lehet az aláíró szerepkörökkel összefüg- 
gésben további kötelezettségvállalásokat is (pl. ügyvédi, köz- 
jegyzői ellenjegyzés, láttamozás stb.). 


A kötelezettségvállalás típusa az aláírói dokumentumból is ki- 
derülhet explicit vagy implicit módon. Például egy (az APEH 
által meghatározott formátumú) adóbevallás típusú üzenet 
aláírása explicit az adatok hitelességének elismerését jelenti. 
Implicit módon az adott dokumentum szövegéből is követ- 
kezhet az aláírás jelentése. 


Aláíró szerepkörök 

Az aláíró szerepkörök az aláíró tevékenységét, jogosultságait, 
illetve egy szervezetben elfoglalt szerepét írhatják le. Az aláí- 
ró neve mellett fontos lehet annak a szervezetben (pl. cégben) 
betöltött szerepe is. Egyes szerződések csak akkor tekinthetők 
érvényesnek, ha egy megfelelő pozíciót betöltő fél (pl. osz- 
tályvezető) írta alá. Sokszor fontosabb arról meggyőződni, 
hogy az aláíró a szervezeten belül milyen pozíciót tölt be, 
mint az, hogy ki is ő valójában. E mellett egy közösségben 
speciális szerepe lehet egyes aláíróknak, pl. az ügyvédeknek, 
közjegyzőknek, különböző hatóságoknak is. A szerepkör jel- 
zése az aláírásban történhet az aláíró állítása szerint (kinyilvá- 
nított szerepkör) és külsőleg hitelesített módon (pl. attribútum 
tanúsítvány segítségével). A szerepkörök és az ezek jelzésére 
elvárt módszer az egyes kötelezettségvállalási típusokhoz is 
köthetők. Így meghatározható, hogy milyen kötelezettségek, 
milyen szerepkör birtokában vállalhatók. 

Az aláírási szabályzatnak, amennyiben definiál aláíró szere- 
peket, azt egyértelműen megkülönböztethető értékek hozzá- 
rendelésével kell tennie, különösen, ha dinamikus, gépileg 
feldolgozható formában teszi. 


Algoritmusok 


Az aláíró algoritmusok közé a nyilvános kulcsú rejtjelező al- 
goritmusok mellett beleértendők a lenyomatképző és feltöltő 
algoritmusok is, s ezek a minimális kulcshosszra vonatkozó 
előírással együtt egyaránt meghatározhatják: 
A Az aláíró által az aláírás során, és ellenőrző által az 
aláírás ellenőrzésékor felhasználható eljárását 
H A végfelhasználói tanúsítványok aláírására és ellenőr- 
zésére szolgáló algoritmusokat 
Hi A szolgáltatói tanúsítványok aláírására és ellenőrzésére 
szolgáló algoritmusokat 
A visszavonási listák aláírására és ellenőrzésére szolgá- 
ló algoritmusokat 
Az attribútum tanúsítványok aláírására és ellenőrzésére 
szolgáló algoritmusokat 
Az időbélyegző előállítására, és ellenőrzésére felhasz- 
nálható algoritmusokat 


B B B 


Az egyes esetekben alkalmazandó algoritmusokat az aláírási 
szabályzatban tisztázni kell. 


Együttes és többszörös aláírások 


Az együttes aláírás több dokumentum ellátását jelenti egyet- 
len aláírással. Erre például egy szerződés és annak különálló 
mellékletei esetében lehet szükség, vagy egy olyan esetben, 
amikor külön nyilatkozatok kapcsolódnak a szerződéshez. Pa- 
pír esetében ezeket össze szokás tűzni, majd egy vagy több 
aláírással látják el a dokumentumot. Mivel az elektronikus 
aláírás a gémkapocs szerepét is átveszi (a sértetlenség biztosí- 
tásával) az elektronikus dokumentumoknál, ilyen esetben 
mindenképp az egyetlen együttes aláírás megtétele javasolt. 

A többszörös aláírások szerepe ennek pont a fordítottja: itt 
egyetlen elektronikus dokumentum van, amit több, különbö- 





ző aláírással kell ellátni. Ezt akkor alkalmazzák, ha a 
dokumentum fontossága több személy együttes aláí- 
rását igényli. Például vannak cégek, ahol csak két 
felső vezető együttes aláírása számít cégszerű aláí- 
rásnak, vagy ahol bizonyos összeg felett, a bank két 
személy aláírását várja el a pénzügyi tranzakciókhoz. Ezen 
aláírások között aztán a legkülönbözőbb kapcsolatok lehet- 
nek az alkalmazott ügylettől és a szervezeti előírásoktól füg- 
gően. Alá, fölé és mellérendeltségi viszonyok, sorrendiségek 
lehetnek kialakítva a vonatkozó szabályokban (pl. szervezeti 

és működési szabályzat). A céges pél- 

dálózások helyett vegyünk most egy 

pártot: a párt elnöke csak akkor fog 


Az elektronikus alá- aláírni bármilyen dokumentumot, ha 
. azt a párt igazgatója, főtitkára vá- 
írás több egy doku- lasztmányi elnöke, központi bizottsá- 


. gi vezetője és frakciófőnöke is ellátta 
mentumlenyomat kó- kézjegyével. De az igazgató is csak 
akkor ír alá, ha a főtitkár már aláírt, és 


dolt értékénél, a választmányi elnök is csak akkor, 
; a j ha a választmány két elnökhelyettese 
hiszen ki kell fejez- együttesen szignózta a dokumentu- 


mot előtte. Minél bonyolultabb a 
szervezet és minél kényesebb a kér- 
déses dokumentum tartalma, annál 
összetettebbek lehetnek az aláírások- 
kal szembeni követelmények. Én pél- 
nyítani kell az aláírás dául, kíváncsi volnék az európai 
uniós ratifikációs okmányra ilyen 
szempontból is. Hagyományos doku- 
mentum esetében ez persze keve- 
sebb gondot jelent, de elektronikus 
dokumentumok esetében alapos át- 
gondolást kíván, hiszen ez esetben az aláírások nem helyez- 
hetők el csak úgy, tetszés szerint a papíron. 

Akármik is az elvárások, azok a többszörös aláírások két alap- 
vető típusába oszthatók. Az első a független aláírások kategó- 
riája, ami párhuzamos aláírásokat jelent. Ebben az esetben az 
egyes aláírások egymásutániságának nincs jelentősége. A má- 
sodik kategória a beágyazott aláírásoké, ahol az aláírások sor- 
rendisége is fontos. 

A legtöbb hétköznapi alkalmazás még nem kezel együttes és 
többszörös aláírásokat, egyelőre annak is örülni kell, ha egyál- 
talán kezel valamilyen elektronikus aláírást. Ha azonban 
olyan feladatot kapnánk, ahol egy szervezet vagy egy tranzak- 
ciós környezet jelenlegi bonyolult aláírási módszereit kellene 
leképeznünk elektronikus formára, alaposan fel kell térképez- 
nünk az elvárásokat, és lehet, fel kell készülnünk a folyton 
változó előírások kezelésére is. 


nie az aláíró 


szándékát, és bizo- 


érvényességét. 





Aláírásformátum 


Az előző részben bemutatott aláírástípusok mellett feltétlen 
szót érdemelnek az aláírásformátumok is, hiszen a két téma 
szorosan összefügg. 

A jelenleg elérhető aláíráskezelő alkalmazások különböző for- 
mátumokat használnak, melyek közül a PKCS í47-es az egyik 
legelterjedtebb. Az elektronikusan aláírt levelek szabványa, az 
S/MIME is erre épül. Ez a formátum csak a legegyszerűbb szol- 
gáltatásokkal bír. Többszörös aláírásokra egyáltalán nem ad 
módot, és az aláírás ellenőrzésére szolgáló adatok közül is 
csak a tanúsítási lánc egyes tanúsítványainak aláírásba fogla- 
lására ad lehetőséget. 


Fr 
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Jóval fejlettebb képességeket tudnak felmutatni az 
XML Signature és XML Advanced Electronic 
Signature formátumok. Ezek lehetőséget adnak több- 
szörös aláírások kezelésére, valamint időbélyegző és 
érvényességi információk aláírásba foglalására is. 


Aláíráskezelő alkalmazás készítése 


Eme igencsak hosszúra (két és fél cikkre) nyúlt búvártanfolyam 
után végre következik a lényeg, ami miatt a sorozatot elkezd- 
tem. Elmerülünk az aláíráskezelő alkalmazások titkaiban. Elő- 
ször is emlékeztetőképpen veszünk pár példát arra vonatko- 
zóan, mi mindenre kell gondolni, mielőtt nekiállnánk bármit 
is fejleszteni, majd átnézzük az aláíráslétrehozás és -ellenőr- 
zés funkcionális modelljét, aztán - a következő részekben - az 
ezeket végző alkalmazások komponenseit, és műveleteit, az 
általuk kezelt adatokat, és az alkalmazásokkal szembeni biz- 
tonsági követelményeket. 


Az aláíráskezelő alkalmazás tervezése 


Az aláíráskezelő alkalmazás tervezésekor, illetve a tervezés 
megkezdése előtt a követelményjegyzék összeállításakor 
számtalan dolgot tisztázni kell. Az eddig elmondottakra 
visszautalva például: 

EI kell dönteni, hogy az alkalmazás hogyan kezeli az aláírási 
szabályzatot. Szabad formátumú szövegként definiáljuk azt; 
vagy gépileg feldolgozható nyelvként, esetleg vegyesen. Egy 
vagy több szabályzat szerint is működőképes lesz-e? Az előb- 
bi esetben mi az a szabályzat, ami szerint működik, utóbbi 
esetben pedig, hogy milyen módon lehet hivatkozni az aláí- 
rási szabályzatra (a lehetséges szabályzatok közül) az aláírás- 
ban, illetve milyen módon választhatja azt ki az aláíró. El kell 
dönteni, hogy az ellenőrzés során hogyan történik a szabály- 
zat feldolgozása, s milyen módon leírt szabályzatokat képes 
feldolgozni az alkalmazás. Látni kell, milyen aláírói szerep- 
körök és kötelezettségvállalások kezelésére kell felkészülni, 
szükség van-e többszörös aláírások kezelésére. 

Tisztázni kell, hogy az alkalmazás milyen közegben fog mű- 
ködni: otthoni vagy irodai, netán nyilvános vagy mobil kör- 
nyezetben. Elosztott alkalmazás lesz-e (az egyes komponen- 
sei hálózati kapcsolaton keresztül kommunikálnak egymás- 
sal) vagy minden komponense ugyanazon a gépen és közvet- 
len kapcsolódó egységeiben fog futni (gép, kártyaolvasó stb.). 
EI kell dönteni, hogy az alkalmazás intelligens kártyát, tokent 
vagy esetleg HSM-modult használ-e majd BALE-ként, vagy 
ezek közül több is előfordulhat, és ezek pontos típusait sem 
árt felmérni. Ha kártya, akkor milyen kártyaolvasó lesz: egy- 
szerű, kijelzős, PINPAD-es, tudásalapú (PIN/jelszó) vagy 
biometrikus azonosítással? Tisztázni kell, hogy az alkalmazás 
teljesen automatikusan ellenőriz-e majd aláírásokat vagy 
szükség lesz humán interfészre. Az aláírás megtétele is tör- 
ténhet teljesen automatikusan, bár a jogszabályok szerint 
csak természetes személy hozhatja azt létre (a természetes 
személy ugyanakkor valószínűleg felhatalmazhat ezzel a jog- 
gal egy alkalmazást. Ha lesz humán interfész, az egyetlen 
nyelvű lesz vagy netán többnyelvű. Tudni kell, hogy az 
aláírásellenőrzés folyamatát részben vagy teljesen átveheti-e 
egy harmadik fél (tipikusan érvényességi szolgáltató). Látni 
kell, hogy milyen algoritmusok használata lehet szükséges az 
aláírás megtétele és ellenőrzése során, beleértve az összes lé- 
pést (aláírás, tanúsítvány, visszavonási lista stb. ellenőrzése), 
s azt is, hogy mik ezeknek az algoritmusoknak a paraméterei. 
Nem mindegy például, hogy a szolgáltatói tanúsítványok 





1024 vagy 2048 bites RSA-kulcsokkal vannak aláírva, esetleg 
DSA-algoritmussal, hiszen nem biztos, hogy a rendelkezé- 
sünkre álló fejlesztőeszközben ezek az eljárások implemen- 
tálva vannak. Nem is beszélve az esetleges licenckérdések- 
ről. Látni kell azt is, hogy milyen szolgáltatók és szolgáltatá- 
sok igénybe vételére fog sor kerülni, s ezeknek mik a jellem- 
zőik. Használva lesz-e időbélyegző, rendelkezésre áll-e 
azonnali érvényességi információs szolgáltatás, a tanúsítvá- 
nyok meddig vannak a tanúsítványtárban, s bár az aláíráshoz 
közvetlen nem kapcsolódik, a titkosítás követelményére is fel 
kell készülni. Ezek alapján kell meghatározni a szükséges 
aláírástípust (lásd II. rész) és az alkalmazott aláírásformá- 
tumot. 


Az aláíráskezelés funkcionális modellje 


Innen kezdve az aláíráskezelő alkalmazásokat és eljárásokat 
nem egységesen vizsgáljuk, hanem két típusra osztva. Az aláí- 
rás létrehozása és ellenőrzése két eltérő folyamatot kíván, me- 
lyekkel szemben mások a biztonsági elvárások. Vannak ezek 
között természetesen átfedések, minthogy mindkét folyamat 
ugyanazon adatokat kezeli. 


Időbélyegző szolgáltató 





ibályzat 
kibocsátó 


Aláírás létrehozó rendszer 
Időbélyegző szolgáltató Tanusítványok 
és érvényességi 

információk 





Háttértár és 
I egyéb Megbízható 
erőforrások összetevők 


Alkalmazás 
specifikus 
Összetevők 


Megbízható [útvonal 


ezerert TT 


Aláírót hitelesítő 


a Aláíráslétrehozás funkcionális modellje 


Az aláírás létrehozását egy aláírás létrehozó rendszer végzi, 
melynek két fő alkotóeleme az aláírás létrehozó alkalmazás és 
a biztonságos aláírás létrehozó eszköz. A kettő között egy 
megbízható útvonalnak kell léteznie a biztonságos adatcseré- 
hez. A biztonságos aláírás létrehozó eszköz egy kriptográfiai 
profil szerint működik, s tárolja az aláírást létrehozó adatot. A 
rendszernek része mindaz a szoftver- és hardverelem, melye- 
ket az alkalmazás és az eszköz használ, és amelyek , csak ott 
vannak". Így például az alkalmazást futtató gép és operációs 
rendszer maga, azok ki és bemeneti egységei, hálózati csatla- 
kozásai, erőforrásai, és az azon futó egyéb alkalmazások. 
Ezek annak ellenére is fontosak, ha az aláírás létrehozásában 
nincs szerepük, mivel ez esetben is kockázati tényezőt jelen- 
tenek. Az operációs rendszer, valamint a gép ki és bementi 
egységei természetesen megkerülhetetlenek. Az aláírási sza- 
bályzatra már számos szót vesztegettünk: ez irányítja az alkal- 
mazás működését. A hitelesítésszolgáltató szerepe itt másod- 
lagos: ő biztosíthatja azokat a tanúsítványokat és érvényessé- 


gi információkat, melyek az aláírásba kerülhetnek, az aláírás 
ellenőrzésének megkönnyítése végett. A hitelesítésszolgáltató 
és az aláíró között előfizetői szerződés áll fenn. Az időbélyeg- 
ző szolgáltató az időbélyegzőt állítja el, mely az aláírás hite- 
les időpontját igazolhatja az aláírás részeként. Az aláíró egy 
aláírói interfészen keresztül kommunikál az aláírás létrehozó 
alkalmazással, mely interfész egyaránt tartalmaz bemeneti (pl. 
billentyűzet) és kimeneti (pl. képernyő) elemeket. A modell 
bemenete az aláírói dokumentum és az aláíráslétrehozó adat, 
kimenete pedig az aláírás maga. Az aláírót hitelesítő adatok 
közvetlenül, vagy az alkalmazás közvetítésével jutnak el a 
biztonságos aláírás létrehozó eszközhöz. Előbbire példa egy 
PIN-PAD-es kártyaolvasó, utóbbira pedig egy token. Az aláí- 
rót hitelesítő adat azonban nemcsak PIN-kód vagy jelszó le- 
het, hanem valami biológiai azonosító is. 





Hítelesítésszolgáltató 


Alkalmazás 
specifikus 
Összetevők 


Megbízható 
Összetevők 


a Aláírásellenőrzés funkcionális modellje 


Az aláírásellenőrzés modelljének fő eltérése a létrehozás mo- 
delljéhez képest, hogy az aláírásellenőrző rendszer nem tar- 
talmaz biztonságos aláíráslétrehozó eszközt. Az aláírásellen- 
őrző alkalmazás a hitelesítési szolgáltatóhoz abból a célból 
kapcsolódik, hogy az aláírás ellenőrzéséhez szükséges adato- 
kat beszerezze (amennyiben azok nem lettek az aláírásba 
foglalva). Az ellenőrzőhöz a kapcsolatot egy ellenőrzői inter- 
fész biztosítja, ami az aláírói interfész megfelelője. A modell 
bemenete az aláírói dokumentum és az aláírás, kimenete pe- 
dig egy eredmény, mely számos értéket felvehet. Lehet rend- 
ben, vagy lehet hibás, mely utóbbi értéket még alaposan to- 
vább lehet cizellálni, mint az látni fogjuk. 


Almási János 
Almasi-Janosodbrt.hu 
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Aláíró (fél) 

Az a természetes személy, akihez a hitelesítésszol- 
gáltató által közzétett aláírás-ellenőrző adatok jegy- 
zéke szerint az aláírás-ellenőrző adat kapcsolódik. 


Ellenőrző (fél) 

Az a személy vagy automatizmus, aki vagy amely az 
aláírásellenőrző adat felhasználásával meggyőződik 
az elektronikus dokumentum hitelességéről és sértet- 
lenségéről, valamint az aláíró személyéről. 


Aláíráslétrehozó adat 

Az aláíróra jellemző egyedi és egyéni adat, mely az 
aláírás megtételéhez szükséges. Tipikusan egy ma- 
gánkulcs, mely egy tanúsítványhoz s az abban tárolt 
nyilvános kulcshoz (aláírás létrehozó adathoz) kap- 
csolódik logikailag. 


Biztonságos aláíráslétrehozó eszköz - BALE 
Olyan hardvereszköz, melynek segítségével az aláí- 
ró az aláíráslétrehozó adatok felhasználásával az 
elektronikus aláírást létrehozza. Az elektronikus aláí- 
rás létrehozásán kívül feladata az aláíráslétrehozó 
adat biztonságos tárolása is. Hétköznapi esetben egy 
intelligens kártya (a kártyaolvasó nem tartozik az 
eszközhöz), különleges igények esetén egy hardve- 
res biztonsági modul. 





Hardveres biztonsági modul - HSM 

Olyan professzionális aláíráslétrehozó eszköz, mely 
az általa nyújtott biztonság vagy aláírási kapacitás 
tekintetében nyújt többet egy egyszerű intelligens 
kártyánál vagy tokennél. Tipikusan egy, a gép rend- 
szerbuszára csatlakozó kártya vagy egy, a géphez 
dedikált vonalon, esetleg hálózati kapcsolaton ke- 
resztül csatlakozó különálló egység. 


Aláírót hitelesítő adat - aktiválási adat 
Az aláíróra jellemző adat, mely a biztonságos aláí- 
rást létrehozó eszköz használatához szükséges. 


Kriptográfiai profil 

Elektronikus aláírás létrehozására és ellenőrzésére 
szolgáló kriptográfiai algoritmusok és egyéb releváns 
eljárások (mint például hash és feltöltő függvények) 
készlete, azok érvényes paramétereivel és beállítá- 
saival. 


Tartalomformátum 

Az aláírói dokumentum típusa, melynek lehetséges 
értékeire vonatkozóan az aláírási szabályzat megkö- 
tésekkel élhet. Elviekben bármilyen állománytípus 
lehet nem csak (szöveges) dokumentumra vonatko- 
zó, de például végrehajtható szoftverkód vagy akár 
mp3 is. Ajánlott aktív kódot nem tartalmazó állo- 
mánytípusokra szűkíteni az elfogadott értékeit (pl. 
rtf, pdf, xml, txt, jpg). 
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Elliptikus görbe 
kriptorendszerek I. TÉ52 


Elliptic Curve Cryptography -— elméleti háttér 


Egy jó ideje egyre több helyen találkozhatunk az ECC betűhármassal, mint egy kriptorendszer megje- 
lölésével. Egyre több előnyéről hallunk: az RSA-nál rövidebb kulcsokkal érhető el ugyanakkora bizton- 
ság, gyorsabb a működése, kisebb a memóriaigénye. Mindezek a SmartCard technológia biztonsági 
eszközeit is az ECC felé fordítják. De mi is ez? Elliptic Curve Cryptosystem, bár gondolom ettől most 
sokan nem lettek okosabbak, nekik (is) szól az a kétrészes cikksorozat, melynek első része következik. 


Az elliptikus görbékről egyre gazdagabb irodalommal és egy- 
re több ismerettel bírunk. A Certicom szerint az elliptikus gör- 
béket, mint algebrai és geometriai elemeket az elmúlt 150 év- 
ben behatóan tanulmányozták és ezeken a tanulmányokon 
alapul a gazdag és mély ismeretek tárháza. Tekintve, hogy a 
Certicom Corporation [certicom] az ECC egyik vezéregyéni- 
sége, sajnos ez a megállapítás csak féligazság, mert az igaz 
ugyan, hogy az elliptikus görbék régóta ismertek, azonban 
kriptográfiai szempontból csak 15 éve vizsgálják őket. Az el- 
liptikus görbék kriptográfiai alkalmazását — egymástól függet- 
lenül — két kutató is javasolta: először Neal Koblitz (University 
of Washington) 1985-ben, majd tőle függetlenül Victor Miller 
(IBM). A jelenleg használt PKI rendszerek (szinte) mindegyike 
a következő három probléma valamelyikének megoldási ne- 
hézségén alapul: 


ma A faktorizálás problémája — IFP (-1970-től, integer 
factorization problem) 

ma diszkrét logaritmus -— DLP (-1970-től, discrete 
logarithm problem) 

ma diszkrét logaritmus az elliptikus görbék felett — ECDLP 
(-1985-től, elliptic curve discrete logarithm problem) 


Sajnos jelenleg senki sem tudja biztosan, hogy e három prob- 
léma elég erős-e, de ennek ellenkezőjét sem bizonyította még 
senki. Jelenleg csak olyan megoldó-algoritmusokról beszélhe- 
tünk, amelyek ,napjaink legjobb algoritmusai", de nem biz- 
tos, hogy elvileg is a legjobbak. Mindenesetre — figyelembe 
véve a ma ismert támadási módokat — az IFP megoldására ma 
ismert legjobb algoritmus messze lekörözi a ma ismert legjobb 
ECDLP megoldó algoritmust. 

Az alábbi táblázatban három kriptorendszer általánosan vagy 
szabvány szerint használt kulcsméreteit láthatjuk. Az egy sor- 
ban lévő kulcsméretek közel azonos biztonságot nyújtanak (a 
NIST ajánlása szerint). Látható, hogy a két legismertebb 
nyíltkulcsos algoritmus (RSA és ECC) kulcsméretei — azonos 
biztonság mellett — ,köszönőviszonyban" sincsenek egymás- 
sál 


A NIST javaslata az egyes kriptorendszerek kulcshosszának 
összehasonlítására: 
ECC modulus 





AES RSAmodulus 





RSA:ECC 





112 56 Sz s: 
161 80 1024 6:1 
256 128 3072 121 
384 Úa 7680 20:1 
512 256 15630 30:1 


Az a tény, hogy az ECC sokkal kisebb kulcsmérettel is bizton- 
ságos, a következőket vonja maga után: 


HA gyorsabb algoritmusok (Azonban az RSA-aláírás 
ellenőrzése és az üzenet titkosítása szinte verhetetlen, 
ha kis nyilvános exponenst használunk, például 
e-65537!) 

H kevesebb továbbítandó és kezelendő adat 

A kisebb tárigény 

A kisebb tanúsítványok. 


Mindezen vélt vagy valós előnyök miatt nem csak a kutatók 
foglalkoznak az elliptikus görbékkel, hanem az üzleti élet szá- 
mára szolgáltatásokat nyújtó cégek is. Ez eggyel több ok, hogy 
mi is megismerjük legalább az alapvető fogalmakat és mód- 
szereket. 

A következő alfejezetekben az elliptikus görbéket először a 
valós számok halmazán definiáljuk és megnézzük az értelme- 
zett műveleteket, a műveletek származtatását, esetenként geo- 
merriai jelentését is. Ne ijedjünk meg a sok ábrától és képlet- 
től, jóval egyszerűbb, mint amilyennek elsőre tűnik! (Ettől füg- 
getlenül sajnos igaz, hogy az ECC matematikailag jóval bo- 
nyolultabb, mint az RSA vagy a Diffie-Hellman, ezért sokkal 
nehezebb megérteni és elmagyarázni vagy bizonyítani, iga- 
Zolni a felhasználók felé... Ha valaki a cikk végére ér, és úgy 
érzi, hogy egy kukkot sem értett meg belőle, nyugodtan lapoz- 
Zon vissza és kezdje elölről!) 


Valós számok halmazán járva — a görbe 


Jelöljünk ki a koordinátasíkon egy P(x,y) pontot! Ha a koordi- 
náták kielégíti az alábbi egyenletet, akkor a P(x,y) pont az el- 
liptikus görbe egy pontja: 





Az elliptikus görbéknek még egy — definíció szerinti — pontjuk 
van: a végtelenben lévő pont, melyet ,O" betűvel jelölünk. 
Nem keverendő össze a valós számok végtelenjével, ami 
megszámlálhatatlanul sokat jelent, míg az ,O"7 pont inkább 
mérhetetlenül messze van (nem mindig...). És ezekkel a pon- 
tokkal fogunk dolgozni! A velük végzett műveletek adják az 
elliptikus görbéken alapuló kriptorendszerek elemi műveletei- 
nek nagy részét. 

Az a és b paraméterek változtatásával újabb és újabb görbé- 
ket definiálhatunk, de nem mindegyik felel meg nekünk. Van- 
nak olyan (a,b) paraméterpárosok, amelyekre igaz, hogy: 





E görbék vagy elmetszik magukat vagy csúcsban végződnek. 
Most nem használjuk ezeket, nem tekintjük őket elliptikus gör- 
bének (szinguláris görbék). Az alábbi három ábrán három gör- 
bét láthatunk azokra az esetekre, amikor DcO , D-0O és D50. 





- Dc0, jó lesz! 





E D-0, ez bizony nem jó! 







az-2 
b:-3 
D:211 


E D50, Ez is rendben van! 


Azt állítottam, hogy a fenti görbék pontjaival fogunk dolgoz- 
ni, lássuk hát miként? 


tech.net S: ELET w i 


Műveletek — geometriai megközelítésben 


A görbék pontjaival mindössze három elvégezhető 
műveletet fogunk definiálni, lássuk most őket egye- 
sével, részletesen! ks 


Előjelváltás — ellentett képzése 


Egy P(x,y) pont ellentett párja R - -P nem más, mint a pont x 
tengelyre tükrözött képe, amely szintén rajta lesz a görbén: 
R(x,-y) 


Összeadás 

Legyen a görbe két különböző pontja P és 0! E két pont össze- 
gét jelölje R, vagyis R-P-4-O. A műveletet a következőképpen 
kell elvégezni: 


1. Kössük össze a P és O pontot egy egyenessel! 

2. Az egyenes egy harmadik pontban metszi a görbét, ez 
a pont lesz -R. 

3. E pont x tengelyre tükrözött képe az előjelváltás szabá- 
lya szerint szintén rajta lesz a görbén és ez lesz az ered- 
mény R pont. 


A művelet lépései az alábbi ábrán követhetők: 





E R-PrO 


P 4 (-P)-? 

Ha eddig egyszerűnek tűnik, akkor most próbáljuk meg P és 
-P pontot összeadni! Mivel P és -P egymás tükörképei az x 
tengelyre nézve, a rajtuk keresztül húzott egyenes párhuza- 
mos az y tengellyel és sajnos nincs olyan harmadik pont, ami- 
ben metszené az elliptikus görbét. Az iménti ábrán látható 
még egy ilyen pontpáros (-R és R): az őket összekötő egyenes 
szintén párhuzamos az y tengellyel és hiába hosszabbítanánk 
meg bármelyik irányba, nem fogja harmadik pontban metsze- 
ni a görbét. Majd csak a végtelenben... Ezért P -- (-P) nem 
számítható ki a fenti módszerrel, de szerencsére van nekünk 
egy O pontunk, amely a végtelenben van. Definíció szerint P 
4 (-P) - O, amiből az is következik, hogy elliptikus görbén ér- 
telmezve P 4 O - P. Hasonló azonosság a valós számok kö- 
rében is van: x § 1 — x. 


2P-? 
Egy pontot az előzőek mintájára adhatunk össze saját magá- 
val. Ha P és O pontokat végtelenül közel visszük egymáshoz, 
akkor P-O lesz. A P és O ponton keresztül húzott egyenes pe- 
dig a P pontba húzott érintővé válik. A folytatást pedig ismer- 
jük: az érintő metszi valahol a görbét és a metszéspont tükör- 
képe lesz a P pont kétszerese. 
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Egy pont megduplázása 


Sajnos azonban itt is van kivétel (lásd a fenti ábrán E pontot: 
ha a pont az x tengelyen szíveskedik tartózkodni, akkor az 
érintő függőleges és nem metszi másik pontban a görbét. Eb- 
ben az esetben definíció szerint a pont kétszerese a végtelen- 
ben van, vagyis 2E-O. Ezek a pontok — melyeknek y koordi- 
nátája zérus — elég furcsán viselkednek, ha 2E után kiszámol- 
juk 3E, 4E, 5E stb. pontokat: 


HA 2£-O 

H 3E- E42E- E410 - E 

H 4E - E43E- E4E-O 

A 5E - E-(4E -— Es0 - E és így tovább. 


Műveletek - algebrai megközelítésben 


Az előzőekben az elliptikus görbén értelmezett műveleteket 
geometriai eszközökkel mutattuk be, de ez nem túl gyakorla- 
tias a digitális számítógépek számára. Kicsit nehézkes érintő- 
ket és húrokat húzkodni, x tengelyre tükrözni, de szerencsére 
a geometriai műveletek eredményét ki is tudjuk számolni... 


Előjelváltás — ellentett képzése 
Ebben semmi újdonság sincs, ha a pont P(x,y), akkor R — -P: 


Ka EX, 
YE -Y, 


Összeadás 
A levezetést mellőzve, csak a végeredményre hivatkozva: ha 
P(xp,yp) és A(xg.yo) nem egymás ellentettje, akkor R — P - O: 


S z (Yp - Yo)/(xe - xo) 


Xez 87 - xp - Xg 
Ya - 8(Xp - Xg) - Yp 
P 4 (-P) —- ? 


Korábban láttuk, hogy ha a két összeadandó pont egymás el- 
lentettje, akkor a rajtuk keresztül húzott egyenes egy függőle- 
ges egyenes, ami O pontban ,metszi" a görbét. Az egyenes 
függőleges voltát jól jelzi az is, hogy az s kiszámításához 
használt tört nevezőjében zérus van. (Figyeljük meg, hogy s a 
PO egyenes meredeksége!) 


2P-? 


Ha yp nem zérus, vagyis a duplázandó pont nem az x tenge- 
lyen van (lásd előző ábra E pontját!), akkor R — 2P: 


s -— (3xp7 t$ a)/(2yp) 
Kazi t SS öl2Kb V 
Ya z B(xp - Xg) - YP 


ga 
a 
- 
s 
a 
a 
- 
u 
mi 
a 
u 
a 





A moduláris aritmetika közbelép - a görbe 


A már megismert egyenletünket egészítsük ki egy kicsit! Ne a 
valós számokon értelmezzük, hanem a moduláris aritmetika 
szabályai szerint: 


Vagyis ha az egyenlet mindkét oldala ugyanazt a maradékot 
adja p-vel történő osztás után, a P(x,y) pont a görbe pontjai 
közé tartozik. (Igazság szerint a p modulus nem feltétlenül 
prím, bizonyos feltételek mellett akár összetett szám is lehet, 
de ez olyan speciális esetnek számít, amelynek megoldása 
sokkal egyszerűbb, mintha p prím lenne. Az ANSI X9.63 szab- 
vány ezért egyenesen kizárja az összetett p modulussal defi- 
niált görbéket a kriptográfiai alkalmazásokból.) Két további 
feltétel: 

1. a P pont mindkét koordinátája kisebb legyen, mint p-1. 

2. valamint 4a" 4 27b" mod p c5 0. 


Néhány gyakorlati indok az áttérés mellet: 

A A valós számokkal való számolás lassú és pontatlan. A 
moduláris aritmetika gyors és pontos, csak egész szá- 
mokkal dolgozik. 

HA A valós" görbének végtelen sok pontja van, a modulá- 
risnak jóval kevesebb. 

HA A moduláris aritmetikában behatárolható a számok ér- 
telmezési tartománya, mert a műveletek operandusa(i) 
és eredménye mindig 0 £ x £ p-1 közé esik. 

HA A moduláris aritmetika alkalmazása megnöveli a 
megoldások számát. 


Ha a ponthalmazt az xy-síkon ábrázoljuk, már nem lesz olyan 
,szép", mint eddig, de megfigyelhető például, hogy továbbra 
is szimmetrikus. Igaz, most már nem az x tengelyre. A követ- 
kező ábra p-11, a-1 és b-0 paraméterek által kijelölt ,gör- 
bét" mutatja: 





B Íme az E: y — x1x40 (mod 11) , görbe" 


Figyeljük meg, hogy: 
A 11 darab pontja van a görbének, 
JA ebből egy darab az origóban (mert b—0), 
FA 10 darab viszonylag véletlenszerűen, de az Y-5,5-re 
szimmetrikusan helyezkedik el, ezért 
HA minden X értékhez továbbra is kettő Y tartozik. 


A görbe pontjainak száma most csak véletlenül egyenlő p-vel. 
Azokat a görbéket, amelyek pontjainak száma megegyezik p- 
vel, rendhagyó görbéknek (anomalous curve) nevezzük és 
gyakorlatilag az összes szabvány tiltja használatukat, mert lé- 
tezik hatékony támadási módszer az ilyen görbét használó 
ECC-rendszer ellen. A pontok számát kiszámolni nem egysze- 
rű feladat, de egy Hasse nevű úriember tétele szerint a pontok 
száma (p-r-1) t 2dp között van. Egy pontra jellemző még egy 
szám, amelyet a pont rendjének hívunk: hányszor tudjuk 
összeadni saját magával, mielőtt O-ba érkezünk? Vagyis ha 
nP-O, akkor n a pont rendje. Ha a pont rendje megegyezik a 
görbe pontjainak számával, a pontot generátorpontnak hívjuk. 


Műveletek a , görbe" pontjaival 


Lássuk, hogyan kell értelmezni a már jól megismert 
művelteinket moduloaritmetikával! Szerencsére nem sok új- 
donságot forgunk látni! 


Előjelváltás — ellentett képzése 


Ha visszaemlékszünk a valós számokon értelmezett görbére, 
ott egy P(x,y) ellentettje az (x,-y) pont volt. Most sincs ez más- 
ként, csak modulárisan kell számolnunk: (x, -yv mod p), ami 
nem más, mint: (x, p-y mod p). Ha megnézzük a fenti példa 
megoldásait, láthatjuk, hogy az egymással szemben lévő pon- 
tok y koordinátáinak összege mindig p-11. 


Például (5,3) és (5,8) 2 348 - 11 
Tehát egy R -— -P pont kiszámolása: 


Xg 5 Xp 
Yaz -Ye mod p. 


Összeadás 


Kicsit nehézkes most olyat értelmezni, hogy ,kössünk össze" 
két pontot és keressük meg a harmadik metszéspontot, főleg 
hogyan ,húzzunk érintőt"? Ezért a korábbi algebrai eredmé- 
nyeket vesszük át a moduláris aritmetika szabályai szerint: 
8 zs (Yp - Yo)/(xp - x9) md p - 

W(Yyp - Yo)(xp - xo)" mod p 


XalS B" JE xi xamodiipi 
Ya - 8(Xxp - Xg) - Yep mod p 


P 4 (-P) - ? 


Ez továbbra sem változik: P -- (-P) - O 


2P-? 


Ha y nem zérus, vagyis a duplázandó pont nem az x tenge- 
lyen van, akkor R — 2P: 
BIE (3 eye Emodt pi E 
$(3x7 4 a)(2y, )7 mod p 
XX, m 87 - 2x, mod p 
Ya 5 8(xp - X.) - Y, mod p 


A probléma: diszkrét logaritmus 


Minden kriptorendszer alapja egy olyan probléma, amit gya- 
korlatilag lehetetlen megoldani. Az ECC-nek is ilyen probléma 
adja a biztonságát, mégpedig a , diszkrét logaritmus elliptikus 
görbék felett" kiszámolásának problémája, röviden: ECDLP. 
(1991-ben néhány kutató elkészítette az RSA algoritmus ellip- 
tikus görbéken alapuló változatát, de néhány évvel később 


többen is megmutatták, hogy az elliptikus RSA-nak 
lECC-like RSAJ nincs számottevő előnye a hagyomá- 
nyos RSA-val szemben. Az ECRSA problémája 
egyébként továbbra is a faktorizálás maradt.) 

Eddig lényegében két műveletet definiáltunk a gör- 
bén: pontok összeadása és egy pont duplázása. Egy pont so- 
rozatos összeadásával (R, R--R, 2R--R, 3R--R) tulajdonképpen 
már szorozni is tudunk. Az így képzett 0-nR pontot a pont 
skalár szorzatának nevezzük, de n meghatározása a szorzat 
alapján nem egyszerű feladat főként, ha a görbét mod p felett 
értelmezzük. 


Legyen egy elliptikus görbe egyenlete: 
Yy - x" 4 9x 4 17 mod 23 
Mennyi az R-(16,5) alapú diszkrét logaritmusa 
9 - (4,5) pontnak? ( 0-nR ) 
Első megközelítésben n kiszámolásához addig 
adogassuk össze a R pontot önmagával, amíg meg 
nem kapjuk 0-t: 


1R-(16,5)  2R-(20,20) 3R-(14,14) 4R-(19,20) 
5R-(13,10) 6R-(7,3) 7R-(8B,7) 8R-(12,17) 
9R-(4,5) F 


Mivel O(4,5)-9R, ezért a O pont R alapú diszkrét 
logaritmusa mod 23 felett: 9. 


Ha most valaki azt mondja, hogy a logaritmus a hatványozás 
inverze és nem a szorzásé (főleg nem az összeadásé), akkor 
annak maximálisan igaza van. De... 


1. A racionális számokon értelmezett ,hagyományos" lo- 
garitmus pontosan ugyanarról szól, mint például a 
Diffie-Hellman kulcscsere megoldása. Ha egy g számot 
x alkalommal összeszorzunk önmagával (a-—g), akkor 
az eredményből és g ismeretében: x-log, a mod p , ha 
létezik. Ez a DLP. 

2. Az ECDLP esetén adott P és O pont a mod p felett ér- 
telmezett elliptikus görbén. Feladat: megkeresni x-et 
úgy, hogy xP-O legyen, ha létezik ilyen szám. 


Úgy tűnik a két probléma jelentősen eltér egymástól, hiszen 
eleve más műveletekről szólnak, az elsőben sorozatos szorzás 
van, a másodikban sorozatos összeadás. Azonban nálam hoz- 
záértőbb matematikusok azt mondják, hogy a DLP szorzása és 
a ECDLP összeadása absztrakt módon ugyanaz. Általánosság- 
ban nem is szorzásnak meg összeadásnak hívják a használt 
műveleteket, hanem egyszerűen csoportműveleteknek (group 
operations). Egy mérnöki szemléletű embernek ez hajmeresz- 
tőnek tűnik, ezért a ,békesség kedvéért" ne keressünk most lo- 
gikát az elnevezésekben, hanem vegyük tudomásul: az ellip- 
tikus görbéken értelmezett sorozatos összeadások (-szorzás) 
inverzét logaritmusnak hívjuk. Pont. 


S mindezt mire lehet használni? Erről lesz szó a második 
részben! 


(Folyt. köv.) 


. Virasztó Tamás 
wacherGwestel900.net 
http://vacher.ípn.hu 
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JP AI, anti-sPHIT 
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avagy Sajnos Pont A Mailboxomban 


gyülekező nemkívánatos adathalmaz 


Napjaink egyik legkellemetlenebb problémájával foglalkozom ebben a cikkben, mégpedig a nem kért, 
de mégis tömegével kapott e-mail üzenetekkel, amelyek eláraszthatnak mindenkit, aki akár csak 
egyszer is küldött valaha egy e-mailt bárhova a saját hálózatán kívülre. 


Elöljáróban vizsgáljuk meg, hogy miként is lehetséges ez, il- 
letve a felhasználók által gyakran feltett kérdések egyikével él- 
ve: , Honnan tudják meg az én e-mail címemet?!". A kérdés- 
ben szereplő rejtett alany, sok esetben valóban rejtett marad, 
hiszen manapság már a SPAM-ek mögött közvetlenül nem a 
gonosz kis marketinges emberkét kell keresnünk, hanem egy 
nagyteljesítményű e-mail motort, amely többezres példány- 
számban generálja az üzeneteket. Olyan hatalmas mennyi- 
ségben születik ma már a reklám-SPAM, hogy ha csak egy mi- 
nimális százalékukra érkezik is válasz, az már elegendő a nye- 
reséghez. A vizsgálódást kezdjük a jó öreg postán, a régi — ma- 
nuális — papírt és tollat igénylő levélfeladásnál. Tehát aki már 
adott fel a postán sima levelezőlapot, az tudja, hogy hogyan 
is néz ki az ilyesmi és mennyire , védett" a rajta található in- 
formáció. 

Ha a feladó neve és címe is szerepel, akkor valóban az összes 
adat a rendelkezésre áll, hogy legközelebb már egyéb célzat- 
tal is megkeressük a két felet. Kulcsszavakra keresve például a 
szövegből kiszűrhető egy adott témakör, amiben a feladó és a 
címzett érdekelt. Megvan minimum egy biztos cím is — a cím- 
zetté — és már mehet is a SPAM. A cikk során szeretném ezt az 
analógiát végig megtartani a postai és a számítógépes levele- 
zés között, mert így könnyebben emészthetővé válik egy-egy 
sokszor bonyolultnak tűnő eset is. 

Mert például az üzenet témájának védelmében a postán a kis 
levelünket egy borítékba bújtathatjuk az avatatlan tekintetek 
elől, míg ez a virtuális világban egy PGP-t, vagy valami hason- 
ló ,borítékot" jelent. A küldeményen mindig lennie kell egy 
címzettnek, a feladó elhagyható (sajnos), illetve ami még 
rosszabb: átírható, hamisítható. Az átvevő posta rajtahagyja a 
nkézjegyét" a levélen, mint ahogyan ezt teszik a levelezőszer- 
verek is. Stb, stb. Egy nagy különbség van csak, mégpedig a le- 
vélküldés ára. A postán ugyanis levelenként célállomásífüggő 
díjat kell fizetni, amit viszont a mátrixban elhagytunk, vagyis 
nincs is definiálva ilyesmi a számítógépes világban. Ennélfog- 
va máris megszülethet az első SPAM-ellenes megoldás: ,Le- 
gyen fizetős az e-mail!" ... Ám ha fizetni is kellene érte, sajnos 
az sem jelentene túl nagy korlátot. Jusson eszünkbe a kis 
szemetesdoboz a lépcsőházban, ami direkt ezért van odaké- 
szítve a postaládák közelébe. Pedig az abba kerülő küldemé- 
nyeket nem ingyen hozta a postás. Képzeljük csak el, mi len- 
ne, ha ingyen jöhetne az a sok-sok felesleges reklám, szóró- 
lap, figyelemfelkeltő színes kiadvány. Még a végén nem ma- 
radna hely a TechNET magazinnak... 

Nos, gondolom ez sokakban elindított egy érdekes gondolat- 
menetet, ezért most ne is menjünk mélyebbre ebben, azon 
egyszerű okból kifolyólag, mert például a virtuális bélyeget 


igencsak nehéz lenne kezelni... Marad tehát a másik módszer, 
hogy megpróbáljuk kivédeni a SPAM-et. Ez nehezebb de egy- 
ben szebb feladat is, hiszen komoly kihívással kell szembe- 
néznie annak, aki ilyesmire vállalkozik. 


A SPAM 


A rövidítés feloldására sok verzió látott már napvilágot. A tel- 
jesség igénye nélkül bemutatnék néhányat: 

A Sending and Posting Advertising in Mass 

A Stupid Pointless Annoying Messages 

A Self Propelled Advertising Material 


A szívemhez mégis az én verzióm — ami a cikk címében is ol- 
vasható - áll a legközelebb. Azért is, mert Sajnos Pont Az én 
Mailboxomban burjánzik a Föld nevű bolygó összes nemkívá- 
natos e-mail üzenete. Van köztük általános reklám, van ami a 
pénztárcám tartalmára áhítozik a kongói kormány nevében, 
van ami több másodperc alatt jelenik csak meg, mert annyi 
kép és link van benne. De vannak olyanok is, amik igen kínos 
helyzetbe hozhatnak abban az esetben, hogyha egy nő kollé- 
gám áll a hátam mögött, amikor megnyitom őket. Ebből a faj- 
tából van ám a legtöbb, napi 10, 20 vagy 50 is akár. Egyik , íz- 
lésesebb" mint a másik. 

Első gondolatra az átlagos felhasználó megnézi a feladó címét 
és kitiltja azt a mailboxából a Rules Wizard segítségével. Ez 
ideig-óráig jó megoldás lehet, de sajnos ugyanannak az üze- 
netnek a következő napon már más a feladója, hiszen mint 
tudjuk az átírható, módosítható. Így állandó csatározásban le- 
szünk egy általunk nem is ismert láthatatlan ellenséggel, 
aki/ami folyamatosan megtalálja majd a postaládánkba veze- 
tő utat. Mert a mi kifelé irányuló leveleink mindegyike ott hir- 
deti magán nagybetűkkel a címünket, így ezen az úton min- 
dig ,visszatalálhat" hozzánk bárki. A probléma rendszer- 
gazdai szempontból is igen összetett, hiszen rendszerszinten 
sem érdemes a feladóalapú kitiltással vesződni. Ezen kívül ko- 
moly probléma lehet az is, hogy az ilyen levelek méretéből 
adódóan sok hely pazarlódik el a mailboxok tárolására szánt 
lemezen is. 

Gondoljunk csak a nyári szünetben magárahagyott mailboxra, 
amire aztán rácsodálkozunk két hét múltán, hogy mi is tör- 
tént, amíg távol voltunk. Van olyan is, amikor egy bizonyos 
méretkorlát elérése után nem fogad több levelet a postafiók, 
és természetesen pont a fontos levelek pattannak majd vissza 
a feladónak, miután betelt a rendelkezésre álló hely. Az alap 
SPAM-trükköket alkalmazó módszereket egy jól konfigurált 
mailszerverrel kivédhetjük. Ilyen például, amikor a feladó cí- 
me nem is e-mail cím, vagy a formátuma kissé rend- és szab- 





ványhagyó. Vagy amikor a feladó mező nincs is kitöltve, illet- 
ve a hálózatunkon belüli másvalaki nevében küldöttnek ál- 
cázza magát egy üzenet, stb. De ha van rendes, szabványos 
feladó, címzett és vírusmentes tartalom, ebben az esetben a 
levél meg fog érkezni, mert látszólag semmilyen probléma 
nincs vele. 


Megoldások, technikák 


A SPAM-szűrés tehát valóban nehéz feladat, mert csak egy hu- 
mán bázisú ítélőszék képes érdemben elbírálni, hogy egy 
adott levél SPAM-e vagy sem. Ezt a feladatot nem bízhatjuk 
számítógépre, legalábbis addig amíg a mesterséges intelligen- 
cia el nem éri ezt a szintet. Van egy módszer azonban, ami 
egészen jól használható, ez pedig a tartalomszűrés. Egy-egy 
adott stringre keres a program, és ha ilyet talál, beállítástól 
függően valamit tesz vele. Ez a megoldás bizonytalan, mert 
nem vizsgálja (nem tudja vizsgálni) a szövegkörnyezetet, ami- 
ben a kérdéses szekvencia szerepel, hanem csak szolgai mó- 
don figyeli annak előfordulását. Ebben az esetben el se mesél- 
hetem e-mailben a kispajtásomnak, hogy milyen gonosz tar- 
talmú levelet kaptam, mert azt is kiszűri majd, hiszen tartal- 
mazza a vizsgált kifejezéseket. De például a rendszergazda 
sem küldheti át e-mailben az erről szóló jelentését a főnöké- 
nek, mert ugyanúgy meg fog felelni a küldeménye a szűrési 
feltételeknek. 

Ez a módszer tehát hatékony, de: problémás és még plusz 
munkát is igényel az adminisztrátor részéről, mert folyamato- 
san nézegetnie kell a kiszűrt leveleket, hogy nincs-e közöttük 
valami tényleg fontos. A másik — és jelenleg a legfejlettebb — 
módszer, ha olyan szűrést alkalmazunk, ahol egy emberekből 
álló csoport előzőleg manuálisan eldöntötte, hogy egy-egy 
SPAM-nek látszó üzenet valóban az-e, vagy sem. Az így ka- 
pott eredményt egy adatbázisban közreadva, már csak azokat 
a jellemzőket kell keresnünk, amit ők előzőleg rosszként defi- 
niáltak, azaz benne vannak az adatbázisban. 

Olyasmi ez, mint a víruskeresők által használt megoldás, 
amikhez mindig megjelenik szépen rendszeresen a frissítés. 
Mivel ez a módszer mindig csak válaszreakciót ad valamire, 
ennek természetéből adódóan előbb van a "kérdés" mint 
ahogy a válasz érkezik. Tehát kiindulásképpen először kapnia 
kell valakinek egy-egy ilyen üzenetet, hogy aztán eldönthes- 
sék róla, hogy bekerül a feketelista-adatbázisba vagy sem. Ez 
így még ezzel a ,hátrányával" együtt is jóval hatékonyabb, 
mint az összes többi megoldás. Főleg az a változat, amit ne- 
kem volt szerencsém kipróbálni és azután élesben is 
üzembeállítani a hálózatunkon. 

Ez a verzió ugyanis megoldja a SPAM fogadást és adatbázisba 
gyűjtést a gyártó cég saját hatáskörén belül, én már csak a 
végeredményt, a SPAM-mentes levelezést kapom. Hogy 
mindezt hogyan? Máris kiderül. 


BrightMail AntiSPAM 


Az [Brightmail]-es címen elérhető cég terméke megvalósítja 
az előzőekben ismertetett adatbázisalapú levélszűrést, és a 
Microsoft SMTP service-szel összebarátkozva lehetővé teszi, 
hogy a rossznak minősített levelek el se juthassanak a 
mailboxokba. A cég ugyanis egy saját kis hálózati szegmenst 
működtet ilyen célokra, ahol a létező összes SPAM-et megpró- 
bálják begyűjteni. Feliratkoznak mindenféle listákra, gyanús 
weboldalakon adják meg e-mail címeiket, ezzel mintegy ma- 
gukra vonják az összes mailbox-éhes SPAM-motor figyelmét. 
Ezt követően már csak el kell dönteni, hogy mi kerüljön be az 


í ú. 
tecn.net tárt tág u d 


adatbázisba. A telepített BrightMail Server, illetve a 
kliens ezt az információhalmazt veti össze az érke- 
zett levelekkel. Ha bármelyik szerepel a feketelistán, 
a beállításoktól függően a következőket tehetjük: 
Forwardolhatjuk egy másik mailboxba, esetleg töröl- 
hetjük is, vagy file-ként gyűjthetjük egy könyvtárban őket. 


Customer Messaging System 





a A SPAM megfigyelése egy másik hálózatban történik 


Van még egy lehetőség is a SPAM gyűjtésre, ez pedig az 
Exchange Foldering Agent. Ez egy olyan beépülő szolgáltatás, 
ahol minden egyes felhasználónak létrejön egy plusz folder a 
mailboxában — mondjuk SPAM néven -— ahova gyűlik a nem 
fontosnak nyilvánított mailek sokasága. Így a felhasználó 
dönthet, hogy mit is kezd az így kapott üzenetekkel. 

Ez persze egy sor kérdést felvet, miszerint van-e szükség 
egyáltalán az ilyen levelek tárolására? Kell-e a felhasználót 
terhelni ilyen problémával? Van-e a levelezőszervernek a 
SPAM-ek által fokozottabban kihasznált tárolókapacitása? 
Ezekre a kérdésekre én negatív választ adtam, így a Foldering 
Agent nem került telepítésre a mi hálózatunkban. Helyette 
egy elkülönített mailboxban tárolom a kiszűrt leveleket egy 
másik szerveren, ahol időnként megnézem, hogy mi az ak- 
tuális Top 10. 

Mivel egy előre definiált adatbázis alapján dolgozik a filter, 
nagyon kicsi annak a valószínűsége, hogy egy valódi — nem 
SPAM - levél is fennakad a hálóján. Egy 250 felhasználós há- 
lózaton másfél hét alatt 7000 elkapott SPAM üzenetből egy 
sem volt rendes levél. Tehát ez így 10096-os biztonságot je- 
lent. Radikális csökkenés után persze, de volt azért egy-két 
SPAM ami mégis becsúszott. Hasonlóan mint egy új vírus, 
amikor nem friss a keresőadatbázis. De ebben az esetben je- 
lentős pozitívumot mutat, hogy a napi 20-30 SPAM helyett he- 
ti 1-2 eshet csak be mailboxonként. 


A BrightMail Telepítése 


A szűrés tehát nem MX alapokon történik. Nem szükséges egy 
új mailszervert sem üzembe állítani, vagy elkonfigurálni a 
DNS MX bejegyzéseit. Ezzel szemben kell egy gép, amire a 
BrightMail Server Software kerül. Ez kérdezgeti majd folyama- 
tosan a Spam Filter Rules adatbázist, amit a cég tesz elérhető- 
vé a neten. A kliens pedig egy MS SMTP service-t futtató gép- 
re kerül — például egy Exchange szerverre — amely majd kér- 
dezgeti az előzőekben említett BrightMail szervert egy álta- 
lunk is meghatározható IP porton keresztül. Lehet a Szerver és 
a Kliens egyszerre egy gépen is, ha elég erős a vas hozzá. A 
kliens installálásának viszont feltétele az SMTP service meglé- 
te az adott gépen. A szűrést az ilyen módon kicsit ,kézbevett" 
SMTP service végzi és a beállításoknak megfelelően dönt az 
elkapott SPAM-ek sorsáról. 
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(B Brightmail Anti-Spam - InstallShield Wizard, xx 





Custom Setup 


Select the program features you want installed, 


-Cick on an icon in the list below to change how a feature is installed. 


JE [riohtmail Administration Tools 
9] Brightmai Cent 
A -Í Brightmail Server 
E 9-] Brightmail Modules 
29 -] Anti-Spam Module 
297] Sieve Module 






This feature reguíres 1261KB on 


9 e] Report Generator Your hard drive. 
Install to: 
C:AProgram Filestgrightmailt ch a 
Installőhield 





hi] 5e canci 


E Az egyes összetevők szétválaszthatóak egymástól 


A terhelés elosztásának szempontjából mindenképp érdeme- 
sebb a szervert és a klienst különvenni egymástól. A default 
kommunikáció kettejük között a 23456-os IP porton zajlik, il- 
letve a Szerver komponens az Internet felől http-n keresztül 
jut hozzá a írissítésekhez. Ha van MS SMTP service a gépen, 
ahol az install MSI-t futtatjuk, a kliens install során ki kell majd 
választanunk a szűrni kívánt SMTP Virtual Server Instance-t, 
mert ugye ebből több is lehet egyszerre. 





(6! Brightmail Anti-Spam - InstallShield Wizard § XI 


SMTP Virtual Server ! 
Select SMTP vírtual server, ! 


Select the SMTP virtual server instance where Brightmai filtering should be enabled: 
Default SMTP Virtual Server si 





- The drop-down ist above contains allof the SMTP virtual server instances detectedon ) 
the local computer. ] w 
! 








etre cine 


Választhatunk az SMTP Virtual Szerverek között 


A szerver install opciói között látható egy Sieve Module név- 
re hallgató program is, ami saját készítésű szabályok definiá- 
lására alkalmas arra az esetre, ha nem lennénk elégedettek a 
program beépített képességeivel. A mellékelt dokumentáció 
részletesen elmagyarázza, hogy miként és hogyan kell létre- 
hozni egy-egy új szabályt a C nyelvre igencsak hasonlító esz- 
közzel. Ritkán lesz rá szükség, viszont ha kell, ott van és na- 
gyon hatékony. 

Mint ahogy azt már említettem, az elkapott SPAM-ek sorsáról 
mi dönthetünk a szerver beállításainak megváltoztatásával. Én 
úgy gondoltam, hogy akár érdekességképpen is, de érdemes 
egy kicsit gyűjteni őket, hogy lássam, mi minden érkezett vol- 
na be ha nincs ez a software. Ezért egy teljesen más szerveren 
— ahol szintén van SMTP service, de nem vesz részt szervesen 
a hálózat levélforgalmában — egy külön mailboxban gyűjtöm 
a napi akár 1000 példánnyal is szaporodó e-mail áradatot. 





)  IftheAnti-Spam Module suspects a message is spam, what action.) 
] 


aa ] should be taken? 





fr Descriptin—————————————————— 


The message is forwarded to the specified email address via the 
! specified SMTP host. 











csek Cancet 


E Mit tegyen a Szerver ha SPAM-et észlel? 


Egy megadott SMTP-n keresztül, egy általunk meghatározott 
mailboxba továbbítható a SPAM. Ennél a beállításnál vigyáz- 
zunk, hogy ne olyan címet adjunk meg, illetve olyan SMTP 
host-ot, ami mögött BrightMail féle ellenőrzés van, mert 
könnyen túlterhelhetjük egy ilyen lépéssel a szűrőmotort. 
(Loop-ba kerülhet szegény.) 







Server Prope: 













Warings 
Server Wamings 
Warmings 


CAProgtam FilesABrightmaitLogstog  condut 
C-XProgram FilestBrightmaiNLogstlog sws.tet 
C-XProgtam FilestBrightmaiNLogstlog-harvest. 


Log file: 
Logging Level 
BERCEÉN EST NÉSSRE KEKI 





- Log File Rollover— 


FR a files eve 





j r] andretain upto log files 











a A logok beállításai is jól szabályozhatók 


Az Administration Tools nevű komponens tartalmaz egy 
Performance Monitort, amivel az aktuális SPAM-szűrési szám- 
lálókat ellenőrizhetjük. Ezen kívül az Admin felületen győ- 
ződhetünk meg arról is, hogy az adatbázis legfrissebb szabá- 
lyai rendben megérkeztek-e hozzánk, illetve itt lehet még 
beállítani a logok részletességi szintjét is. 


Füzesi Szabolcs 
fuzesisz2osi.hu 
MCSA 


gl Profiler 


Aki SOL Serverrel foglakozik, akár fejlesztőként, akár rendszergazdaként időről-i- 


e 


dőre találkozhat , rejtélyes" esetekkel. Amikor valami okból nem úgy fut egy alkal- 
mazásunk, ahogy mi elvárjuk, és sehol nem találjuk a hiba okát. Ilyenkor érdemes 
az SOL Profilerhez fordulnunk. Ez az eszköz az SOL Server részeként sokszor se- 


gítheti munkánkat. 


Mióta SOL Serverrel dolgozom, többször fordultam bizalom- 
mal az SOL Profilerhez. Túlnyomó többségben hibakeresésre 
használtam, kihasználva a Profiler azon tulajdonságát, hogy 
az SOL Serveren történt minden eseményt megmutat, amire 
csak szükségem van. Bár ez közel sem minden, amit ezzel az 
eszközzel elérhetünk. 

A Profiler elsődlegesen az SOL Server monitorozására szol- 
gál. Az így kapott eredményhalmazt viszont már használhat- 
juk teljesítményelemzésre, hibakeresésre, tesztelésre vagy 
akár adott táblához indexvarázslásra is. 

Az első lépésben indítsuk el a Profilert a start menüből vagy 
az Enterprise Manager Tools menüpontjából: egy üres ablakot 
kapunk. Indítsunk egy új szálat a New Trace ikonra kattintva 
vagy a File-2New-:New Trace menüpontot választva! 

A megjelenő ablakon adjuk meg melyik SOL Serverhez sze- 
retnénk kapcsolódni (sőt egy pipa elhelyezésével azt is elin- 
tézhetjük, hogy az adott SOL Server el is induljon, ha esetleg 
le lenne állítva). A bejelentkezéshez pedig használjuk azt az 
autentikációs módot, amely számunkra a megfelelőbb. 


Connect to SOL Server 


gj SOL Server: (loca) y va 


[7 Start SOL Server if it is stopped 


Connect using: 
(s Windows authentication 


C SOL Server authentication 


Pe A, 
———,—,,—— 


OK Cancel Help 
— Came [He] 


E Kapcsolódjunk a kiválasztott SOL Serverhez 


Miután kiválasztottuk mondjuk a helyi szervert, állítsuk be a 
futtatás körülményeit. Az általános beállításoknál adjuk a 
Proba nevet a szálnak, és állítsuk be, hogy az eredményt 
mentse el a Profiler egy proba.trc fájlba. Ebből a fájlból bár- 
mikor visszaolvashatjuk az SOL Serveren adott időszakban 
lejátszódó eseményeket, elemezhetjük az így kapott adato- 
kat, sőt vissza is játszhatjuk őket. Ez igen hasznos lehet akkor, 
ha egy adott rendszerben hirtelen megnövekszik a felhaszná- 
lók száma, és szeretnénk megfigyelni mennyiben változott 
emiatt az SOL Server teljesítménye. 





Persze nem muszáj a Profiler által visszaadott értékeket el- 
mentenünk, ez csupán egy lehetőség. 


Trace Properties fe 21 


General  Events ] Data Columns ] Fiters ] 


B Trace name: Untitled - 1 
Trace SOL Server: LONDON 3] 


Use the following trace template: 





Template name: SOLProfilerstandard y 
Template file name: jmplatesXSOL ProfileXSOLProfilerStandard.tdf a 
[7 Save to file: 


icrosoít SOL ServeNMSSOLYtracetproba tre 
5 


Set maximum file size (MB) 
[7 Enable file rollover 
TT Server processes SOL Server trace data 


El 
Ég 


6/ 6/2003 r]I[ 4.25.039PM -H 


TT Savetotable: 


TT Set maximum rovos (in thousands): 





IT Enable trace stop time: 





Run Cancel Help 





E Általános beállítások 


Ha mégis úgy döntünk, hogy elmentjük az eredményhalmazt, 
fontos beállítani, maximum mekkora lehet az elmentett .trc 
fájl. Ha a Profilerben egy trace-t sokáig futtatunk, könnyen 
óriásivá duzzadhat az elmentett fájl. Ha az Enable file 
rollovert bejelöljük, a Profiler elkezdi felülírni a maximális 
méretét elért fájlt. Ha jobban szeretnénk SOL táblát használni 
az eredmények rögzítésére, erre is lehetőség van. Itt azt kell 
megadni, hogy melyik táblába mentünk és maximum hány 
ezer sor szerepelhet benne. 

Ha egy trace-t csak elindítani szeretnénk, és azt akarjuk, hogy 
később automatikusan álljon le, az Enable trace stop time-nak 
adjunk meg egy másodpercre pontos értéket. 


Az első lapon könnyedén túljutottunk, most állítsuk be milyen 
eseményekre vagyunk kiváncsiak! 
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Trace Properties 


General Events ] Data Columns ] Fiters ] 


8 Select the SOL Server event classes you want to trace. 





Selected event classes: 


— Security Audit 
(§ Database Audit Login 
6 Errors and Warnings Audit Logout 


Locks . - Sessions 
Objects Aday ExistingConnection 
Performance j 7 Stored Procedures 
Scans RPC:Completed 

7 Security Audit 4 c Remove z TSOL 
Server SOL:BatchCompleted 
Stored Procedures 
Transactions v 


Available event classes: 


7 Cursors s. 
Collection of events produced when cursors are created, used and deleted. 


E Válogassunk az események közül 


Alapértelmezésben a be és kilépések, létrejött kapcsolatok, a 
lefutott tárolt eljárások és Transact SOL parancsok kerülnek be 
a megfigyelt elemek közé. Persze még rengeteg mindenből 
válogathatunk. Nézzünk néhány eseményosztályt: 

BA Cursors: Cursorokkal kapcsolatos események. Például 
cursor létrehozása vagy törlése. 

IA Database: az adat- illetve logfájlok növekedését és 
csökkenését figyelhetjük vele. 

A Errors and Warning: Hibák és kivételek figyelése. Pél- 
dául azt is megnézhetjük, hogy történik-e bejegyzés az 
ErrorLogban vagy az EventLogban. 

H Locks: Zárolások. Igazán hasznos dolog a zárolások fi- 
gyelése, főleg egy többfelhasználós rendszerben, ahol 
esetleg többen várnak arra, hogy valaki végre elenged- 
jen egy táblát. 

TA Security Audit: ide tartozik minden, ami biztonsági hi- 
telesítést igényel, vagy azzal kapcsolatos. 

A Stored Procedures: A tárolt eljárásokkal kapcsolatos 
összes esemény. Például tárolt eljárás futtatásának kez- 
dete, befejezése, újrafordítása. 


Egyelőre hagyjunk mindent alapbeállításon, majd később mó- 
dosítunk rajta. 


A Data Columns panelen megadhatjuk, milyen oszlopai le- 
gyenek a visszaadott táblázatnak. A legfontosabbak már a ki- 
választottak között vannak, de hozzáadhatunk a listához 
újabb elemeket is a baloldali oszlopból. 

Az ablakban az utolsó panel a Filter. Itt adhatjuk meg, hogy az 
összes SOL forgalom közül mi kerüljön a listánkba. Egy szűrő 
már be van állítva: 





Azaz az SOL Profiler által generált eseményeket nem jelenít- 
jük meg. (Nem sok értelme lenne a vizsgált SOL utasítások kö- 
zé bekeverni a vizsgáló eszköz tetteit. Ez olyan helyzetekhez 
vezethetne, mintha a látszerész arra a következtetésre jutna, 
hogy MI rosszul látunk, mert ő szemüveges.) 





Ha további szűrőt szeretnénk megadni, megkeressük a megfe- 
lelő elemet (például DatabaseName) és a lenyíló ágban a Like 
vagy a Not Like feltételhez beírjuk a megfelelő értéket. 


EAT 


General ] Events ]) Data Columns  Fiters )] 


Specily the criteria for determining which events to capture. 


Irace event cíteriat 


SOL Profiler 
1. CkentProcessID 
(7 ColumnPermissions 
CPU 
1 DatabaselD 
- DatabaseName 

- Like 

(INorthwind 
(1 Not like 


TT Exciude gystem IDs 
DatabaseName 
Name of the database in which the statement of the user is running. 








E Szűrjünk a Northwind adatbázisra 


Ha minden beállítással végeztünk, futtassuk a trace-t! 

A legelső bejegyzés csak azt mutatja, hogy a trace elindult, 
majd a jelenleg létező összes kapcsolatot kiírja: ki jelentkezett 
be, milyen alkalmazásról és milyen beállításokkal. Ezután kö- 
vetkeznek a végrehajtott események. Itt csak azok az esemé- 
nyek jelennek meg, amelyeket előre beállítottunk. Emlékez- 
zünk vissza, jelenleg ez az alapértelmezett, azaz a be és kilé- 
pések valamint az eljáráshívások és utasításvégrehajtások je- 
lennek meg. 

Nézzük, mi történik, ha létrehozunk egy táblát. Hajtsuk végre 
Ouery Analizerből a következő utasítást: 





CREÁATE TABLE proba ( oszlop! int. 


SOL:BatchCompleted 





£ 
-REATE TABLE proba 


oszlop! int, 
oszlop2 nvarchar[30]) 


Ekkor megjelenik egy sor a Profilerben, ahol láthatjuk, hogy 
végrehajtódott ez a parancs a Ouery Analyzerben, azonban 
hogy valóban létrejött-e a proba tábla, azt már nem látjuk. Mi 
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sem jobb példa erre hiányosságra, ha még egyszer végrehajt- 
juk ugyanezt az utasítást, a Ouery Analyzer kiabál, hogy nem 
tudja végrehajtani a parancsot, mert már létezik ilyen tábla, a 
profilerben viszont úgy jelenik meg, mintha minden rendben 
lenne. 

Vegyünk fel tehát néhány eseményt a listába, hogy többet tud- 
junk, többet lássunk! 

Először állítsuk le a trace-t (eszköztáron a stop gomb vagy a 
File/Stop trace... menüpont), majd szerkesszük a tulajdonsá- 
gokat (eszköztáron a Properties gomb vagy a File/Properies 
menüpont. Vegyük fel az Errors and Warnings eseményosz- 
tályból az Exceptiont, valamint az Objects osztályból az 
Object:Created eseményt. Az oszlopokhoz adjuk hozzá az 
ObjectName és az Error oszlopokat, majd futtassuk újra a 
trace-t! (Ekkor, ha az eredményhalmazt elmentjük, az adott 
fájl vagy tábla felülíródik.) 

Nézzük, mi történik, ha újra létre szeretnénk hozni a proba 
táblát anélkül, hogy töröltük volna előtte, vagy egy, az előző- 
höz hasonló probat táblát készítünk. 
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2714 Error: 2714. Severity: 16. State: 6 SOL 
SOL:BatchCompleted CREATE TABLE proba (oszlop int... SOL 
Object.Created probal SOL 
SOL: BatchCompleted CREATE TÁBLE probat ( oszlopti.. SOL 


E Az Exeption is megjelenik, ha felvettük a megjeleníten- 
dő események közé 


Rögtön láthatjuk, hogy a parancs futtatásával létre is jött a 
proba 1 tábla, viszont a proba tábla újbóli létrehozása 2714- 
es hibaüzenettel elszáll. 
A fenti példából is látszik, hogy sok minden történhet a 
Serveren, és attól, hogy nem tudunk róla (mert például nem 
megfelelő a hibakezelésünk), azért még ott van. 
Visszajátszás 
Ha már elmentettük egy adott időszak eseményeit, bármikor 
előszedhetjük, elemezhetjük, sőt vissza is játszhatjuk az adott 
eseményeket. 
Készítsünk proba.trc fájlt a következő módon: 
1. Nyitunk egy új trace-t a Profilerben. 
2. Megadjuk, hogy az eredményhalmazt mentse egy 
proba.trc fájlba. 
3. Az alapbeállításokkal kapcsolódjunk a helyi SOL 
Serverre. 


Mivel én már az előzőekben készítettem egy proba táblát a 
Nothwind adatbázisban, ezt a táblát fogom használni. Ouery 
Analyzerből futtatva hajtsuk végre a következő utasításokat: 





Majd állítsuk le a szálat. Ezek után töltsük vissza az így elmen- 
tett proba.trc fájlt (File/Open menüpont). 

Ekkor megváltozik az eszköztár, és a futtatás ikonjai helyett a 
visszajátszás (replace) ikonjai jelennek meg. 
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E Fájlbetöltésekor megváltozik az eszköztár 
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Visszajátszhatjuk az összes lépést egyszerre, lépé- 
senként, vagy csak a kijelölt sorokat. Amikor újra um 
futtatjuk a tárolt lépéseket, meg kell adnunk, hogy ul 
mely szerveren szeretnénk ezt megtenni, hogy lehe- a 
tőleg ne az éles adatbázisba tegyünk bele kétszer 
mindent. Továbbá megadhatjuk, hogy ugyanolyan sorrendben 
történjen a futtatás, mint az eredeti sorrend, vagy többszálú, 
párhuzamos futtatást szeretnék. 


Replay SOL Server BE 2 


Bi Select the destination server and replay options 





Replay SOL Server: [EonDon 
Dutput file name: I al 
Replay Options 


G Replay events in the order they were traced. This option enables debugging. 
C Replay events using multiple threads. This option optimizes performance and 
disables debugging. 


7 Display replay results 








Start I Cancel I Help 


5 A visszajátszás beállításai 


Gyakorlati hasznok 


Most, hogy átfutottuk, mire is jó nagyjából a Profiler (az Index 
Tuning Wizard kivételével, hisz erről már korábban olvashat- 
tak ezen oldalakon), nézzük a gyakorlatban mikor jöhet jól a 
használata. 


Tesztelés 


Mielőtt egy alkalmazást kieresztenénk a kezeink közül, kipró- 
báljuk, teszteljük, hogy tényleg megfelelően működik-e. Igaz, 
az általunk fejlesztett alkalmazásokban a hibák 20-3096-t va- 
lószínűleg nem találjuk meg, de azért a maradék 7090-ot ér- 
demes kiszűrni. 

Előfordult már velem is, és persze nem vagyok ezzel egyedül, 
hogy egy eljárás tökéletesen működött, amíg Ouery 
Analyzerben futtattam. Azonban amint egy webalkalmazásból 
hívtam meg ugyanezt az eljárást, már nem volt tökéletes. Néz- 
zük meg egy konkrét példán keresztül (a teljesség igénye nél- 
kül), mi az, amibe ilyenkor belefuthatunk! 

Készítsünk a Northwind adatbázisban egy GetProbaOszlop1 
eljárást, ami visszaadja a proba tábla első oszlopából a felté- 
telnek megfelelő sorokat. 


Ha ezt Ouery Analyzerben lefuttatjuk, mivel van hozzá jo- 
gunk, tökéletesen lefut. Azonban, mi van akkor, ha ugyanezt 
egy weboldalról szeretnénk megtenni. 
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Mivel a biztonsági beállítás SSPI, az adott parancs az 
IUSR computername nevében fut(na). Ha azonban nincs fut- 
tatási joga, akkor már kibukik a hiba. Ezt megfelelő hibake- 
zeléssel könnyedén észrevehetjük, de a Profiler is szépen 
mutatja: 





SOL:BatchCompleted 


exec GelProbaOszlopi! 


E Ha futatthatnánk ezt az eljárást a Success oszlopban 1- 
es szerepelne 


Adjunk futtatási jogot a IUSR computername-nek a 
GetProbaOszlop1-re, és ezt a hibát ki is küszöböltük! 

Most tegyük fel, hogy a fenti VBScript kódban szereplő index 
paramétert egy formból kapjuk. Mi van, ha ezt a paramétert a 
felhasználó nem töltötte ki? Akkor bizony default értékkel hí- 
vódik meg a GetProbaOszlop1 . Tehát nem úgy, mintha NULL 
értéket tartalmazna, vagy egy üres stringgel lenne egyenlő, ha- 
nem default! Ilyenkor kliensoldalon egy hibaüzenetet kapunk, 
hogy hiányzik egy paraméterünk. 


Audit Logout 1 1 


RPC.Completed 





exec GetProbaOszlopi default. "a 


E Hanem adunk a paraméternek értéket, akkor az 
alapértelemezett értékkel hívódik meg - ha van ilyen 


Bizony, mi nem állítottunk be alapértelmezett értéket erre a 
paraméterre, miért várnánk el, hogy visszaadjon bármit is ez 
a szegény eljárás? Ilyenkor vagy kliensoldalon dolgozzuk fel 
ezt az eshetőséget, vagy kicsit átszabjuk a tárolt eljárást. 
Előfordulhat az is, hogy elvileg minden paraméter és a jogok 
is stimmelnek, de mégis elveszik valahol a recordset tartalma. 
Ilyenkor is jól jön a Profiler. Ha az SOL Serveren minden rend- 
ben, azt az eredményhalmazt kapjuk vissza, amit kell, akkor 
bizony valahol kliensoldalon van a hiba! 

És folytathatnám a példák sorolását, amelyek alátámasztják a 
Profiler hasznosságát. 


Karbantartás, teljesítményelemzés 


Bármilyen szépen is működött egy felhasználó esetén az álta- 
lunk készített alkalmazás, ez még nem jelenti azt, hogy 20-30 
felhasználó esetén is ugyanolyan jól fog üzemelni. Sőt lehet, 
hogy már 2 júzer esetén is percekre , behal". 

Ilyenkor érdemes elmenteni időnként az SOL Serveren történő 
eseményeket: a Profiler pont jó erre. 

Aki villámolvasó, valószínűleg azzal is megbirkózik, ha 
realtime figyeli a becsapó kéréseket, zárolásokat, zárolás 
feloldásokat, hibaüzeneteket, parancsvégrehajtásokat. Valljuk 
be, azért a többségünk nem olvas 10-20 vagy több sort egy- 
szerre, bár járnak közöttünk igazán profik, akik valószínűleg 
egy másik bolygóról érkeztek. Viszont az elmentett trace-t már 
mi, emberek is könnyedén elemezhetjük. 

Jó tudni, hogy mely lekérdezések futottak legtöbbször. Kide- 
rülhet akár az is, hogy az általunk készített index egy táblán 
nem éppen a legmegfelelőbb. Megtalálhatjuk azokat a paran- 
csokat, amelyek a legtovább futnak, a legtöbb erőforrást 
igénylik, így célszerű optimalizálni őket, ha eddig nem tettük 
meg. 

Mindezt pedig úgy, hogy — hála a szűrőknek — csak a szá- 
munkra szükséges sorok jelenjenek meg. Persze nem elég 
hangsúlyozni, hogy tudnunk kell, mit keresünk! 
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Übjektum Drientált 
kalmazástejlesztés I. 


OOP, OOA, UML, DP, RUP, ER, ORM,... Sokáig folytathatnám még a HBR-eket O, amelyek a szoft- 
vertervezés és -fejlesztés során felmerülnek, és amelyek tengerében nagyon könnyen el lehet veszni. 
Az útkeresés során látni fogjuk, hogy nem elég, ha az ember ismeri a rövidítések jelentését, a lexiká- 


lis tudás mellett rengeteg egyéb képességre kell szert tennünk. 


Az említett rövidítésekkel nap mint nap találkozhatunk mun- 
kánk során. Vannak, akik otthonosan mozognak ebben a vi- 
lágban, sokan pedig az első, gyors sikerélmény elmaradása 
miatt örökre kiábrándulnak az ide kapcsolódó módszerekből. 
Vannak azonban, akik szeretnék megtanulni, viszont nem tud- 
ják, hogyan induljanak el. Számukra szeretnék egy kis segítsé- 
get nyújtani. 


A programozás kezdetben egészen mást jelentett, mint nap- 
jainkban. Informatikai léptékkel számolva ma már történelem- 
nek nevezhető, amikor az operátorok teljhatalmúak voltak ab- 
ban az értelemben, hogy minden egyes számítógép-hozzáfé- 
rés rajtuk keresztül történt, és ha valami miatt nem fordult 
vagy hibás futási eredményt produkált programunk, kérhet- 
tünk új időpontot, és kezdődött elölről minden. A szoba- sőt 
csarnokméretű gépek mindemellett annyiszor meghibásodtak, 
hogy már önmagában ez is lényegesen rontotta a hatékonysá- 
got. Ezt az időszakot már csak elbeszélésekből ismerem, de el 
tudom képzelni, milyen lehet ily módon fejleszteni például 
egy háromrétegű adatbázis-alkalmazást... (tudom-tudom, se- 
hogy!) 

A következő lépés az volt, hogy a fejlesztők már önmaguk is 
odaférhettek a számítógépekhez. Ez természetesen előrelépést 
jelentett, de a gépek továbbra is osztottak voltak, így a prog- 
ramozók még mindig csak meghatározott időszeleteket kap- 
tak. Ezt az időt kellett úgy beosztani, hogy minél többet halad- 
jon a fejlesztés, s ha az idő lejárt, lehetett újra feliratkozni — 
esetenként a következő hónapra. Abban az egyben biztos va- 
gyok, hogy akkoriban munka közben igencsak kevés kávészü- 
netet tartottak. . . 

Egyszer aztán elérkezett az az időszak is, amikor a fejlesztők 
saját gépen dolgozhatnak. Annak idején jómagam Commodo- 
re-on kezdtem, ahol már az is művészet volt, ha az ember le 
akarta menteni a munkáját, vagy vissza akarta tölteni a kazet- 
táról (játszani azért már akkor is jókat lehetett). BASIC-ben 
próbáltunk nagyot alkotni, a sorszámozott programsorok és a 
GOTO-k között igyekeztünk eligazodni. 

Aztán egyszer csak megismerkedtem a PC-vel és a Pascal 
nyelvvel. Azt hiszem, innen kezdve nem volt megállás... 


Programnyelvek osztályozása 


De vajon mi az, ami egyik programnyelvet megkülönbözteti a 
másiktól? Akkoriban óriási élmény volt, ha egy BASIC utasítás- 
sorozat működött, ma pedig már csak csendben mosolygok 
rajta. Vajon miért? 

Az általam most vizsgált programnyelvek mind az iteratív 
nyelvek családjába tartoznak. A másik nagy csoport a dekla- 


ratív nyelvek csoportja, ide tartozik pl. a Prolog, az SML, az 
SOL vagy az XSL. Ezek közös tulajdonsága, hogy leíró nyel- 
vek, azaz adott problémára vonatkozó statikus tényeket írnak 
le, semmit nem mondanak arról, hogy ezeket a statikus tudás- 
elemeket milyen módon (mely eljárás szerint) kell a problé- 
mamegoldás során felhasználni. Többnyire a matematikai l1o- 
gika kifejezésmódjára támaszkodnak, így bizonyos kijelenté- 
sek alapján automatikusan új kijelen- 
tések vezethetők le. Ez a lehetőség 
szolgál a mechanikus tételbizonyítás 
alapjául is. Fontos alkalmazási terü- 
letként említhető a mesterséges intel- 
ligencia, a természetes nyelvek fel- 
dolgozása, elektronikus berendezé- 
sek tervezése, ellenőrzése, analizálá- 
sa, stb. 


Az objektumorientált 
paradigma segítségé- 
vel gyorsabban és 


biztonságosabban Ér- 

Az iteratív nyelvek ezzel szemben a 
hetünk célt a szoÍtvuer- megoldás hogyanjára helyezik a 
hangsúlyt: nekünk kell megmonda- 
nunk, mit milyen algoritmus alapján 
kell végrehajtani. 
Ez persze nem egyszerű feladat... 


fejlesztés területén. 


Kezdetben a programozók még nem ismerték az objektumo- 
rientált megközelítést: a programok függvényekből és metó- 
dusokbáól álltak, egyetlen óriási blokkba szerveződve. Később 
kialakult a strukturális megközelítés, azaz lehetőség volt arra, 
hogy a program különböző részeit különböző modulokba, 
különálló fájlokba helyezzük, növelve ezzel az áttekinthető- 
séget és a kezelhetőséget. Ez a megoldás már szebb és hasz- 
nálhatóbb volt, azonban még mindig nem az igazi... 
1968-ban a NATO szoftverfejlesztési konferenciáján vezették 
be a szoftverkrízis fogalmát. A fejlesztők számára világossá 
vált, hogy az egyre bonyolultabb programok már nem fejleszt- 
hetők a régi strukturált módszer segítségével, vagyis a minősé- 
get nem lehet tartani. A , tünetek", amelyek alapján erre a ki- 
jelentésre jutottak, a következők voltak: a rendszereket egyre 
nagyobb késéssel szállították, működésük megbízhatatlan 
volt, és egyre kevésbé teljesítették a megrendelők igényeit. A 
válságból kivezető út már csak valamilyen új, forradalmi 
szemlélet, módszer megjelenése lehetett. Így született meg az 
objektumorientált paradigma, amelynek segítségével gyorsab- 
ban és biztonságosabban érhetünk célt a szoftverfejlesztés te- 
rületén. 

Természetesen nem valószínű, hogy ezzel egyszer s minden- 
korra megoldódott a szoftverfejlesztők összes gondja. A széle- 
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sebb lehetőségeknek köszönhetően a szoftverekkel 
támasztott igények egyre nőnek, és az aktuális tech- 
nológia, a módszertanok nem biztos, hogy lépést 
tudnak tartani ezekkel. Ilyenkor újabb kivezető utat 
kell keresni... 


Az objektumorientált módszertan 


De mit is jelent, valójában ez az új szemléletmód? Mi tulaj- 
donképpen az objektumorientáltság? 

Először is azt kell tisztáznunk, mit takar a moduláris progra- 
mozás fogalma, s csak ezután érdemes továbblépni. A ,szép" 
szoftver lényeges tulajdonsága, hogy áttekinthető, érthető, jól 
kezelhető modulokbál álljon. Ehhez alapvetően két eszköz áll 
rendelkezésünkre: az absztrakció és a dekompozíció. Az 
absztrakció során a feladat szempontjából lényeges dolgokat 
kiemeljük, a lényegteleneket pedig elhagyjuk, a későbbiek so- 
rán nem vesszük figyelembe őket. Például ha egy autót aka- 
runk modellezni, lényeges a típusa, az ajtók száma, a légzsák 
megléte, de például ha a feladat csupán az autó biztonságá- 
nak vizsgálata, a színe nem lényeges tulajdonság, ezzel nem 
kell foglalkoznunk. (Hacsak nem pszichológiai tesztet vég- 
zünk, és azt akarjuk bebizonyítani, hogy a kicsi, piros női au- 
tók a legveszélyesebbek az állatvilágra...) 

A dekompozíció során az így redukált feladatot részfeladatok- 
ra, modulokra bontjuk, hiszen a kisebb részeket sokkal egy- 
szerűbb áttekinteni és kezelni. A részfeladatok megoldása 
után azokat ismét egy egésszé összerakva kapjuk az eredeti 
feladat megoldását. 

A moduláris programozásnak több alapelve is van, ezek közül 
a legfontosabbak: 


HA ,Oszd meg és uralkodj": A modulok egymás működé- 
sébe nem szólhatnak bele, de elvárható, hogy a saját 
feladatukat tökéletesen végezzék. A modulok belüli kö- 
téseknek erőseknek (kohézió), a modulok közöttieknek 
pedig lazáknak kell lenniük (csatolás). Így a program 
sokkal áttekinthetőbb lesz, a hibák egyszerűbben ki- 
szűrhetők és javíthatók. 

HA Az információ elrejtése: Az egyes modulok csak a saját 
adataikon dolgozzanak, csak akkor használjanak közös 
adatokat, ha az feltétlenül szükséges. 

H A döntések elhalasztása: Csak akkor hozzuk meg a 
döntéseket, amikor már feltétlenül szükséges, és min- 
den ismeretünk megvan hozzá. Máskülönben előfor- 
dulhat, hogy valamely későbbi szakaszban, az újabb 
ismeretek megszerzésével felül kell bírálni döntésün- 
ket. 

A A döntések kimondása: A feladat megoldása során min- 
den döntést dokumentáljunk. Ha ezt elmulasztjuk, 
fennáll a veszélye, hogy később nem emlékszünk, 
rosszul emlékszünk, esetleg kollégáinkkal kerülünk el- 
lentmondásba. 


A modulokra bontás kétféleképp történhet: ha fentről lefelé 
építkezünk, az eredeti feladatot bontjuk egyre finomabb és fi- 
nomabb részekre, modulokra; ha alulról felfelé haladunk, a 
szoftvert már meglévő, kész modulokból állítjuk össze. 


Az objektumorientált gondolkodásmód nagymértékben ha- 
sonlít az emberi gondolkodáshoz: a körülöttünk lévő tárgya- 
kat, objektumokat csoportosítjuk, rendszerezzük, a közöttük 
lévő kapcsolatokat próbáljuk felderíteni. Az objektumorientált 


(00) program kommunikáló objektumok összessége, ahol 
minden objektumnak jól meghatározott szerepe és felelőssége 
van. Az objektumban tárolhatunk adatokat, amelyek a feladat 
végrehajtásához szükségesek, illetve funkciókat, amelyek az 
adatokon végzett műveleteket definiálják. Az objektummal az 
interfészén keresztül kommunikálhatunk, továbbá az objektu- 
munk mindig valamilyen állapotban van. 

Példaként maradjunk az autós példánál. Egy autóobjektum 
adatai lehetnek az ajtók száma, a légzsákok száma és elhe- 
lyezkedése, a motortérfogat stb. A funkciók az indulás, féke- 
zés, kanyarodás és így tovább. Az autó interfésze a kormány 
és az egyes pedálok, ezeken keresztül adjuk meg, mit és mi- 
lyen paraméterekkel szeretnénk végrehajtatni (például a Kor- 
mány interfészen keresztül meghívjuk a Kanyarodj metódust a 
ljobb, 90"] paraméterekkel). A kanyarodás során az autó álla- 
pota megváltozik, például az IÉszakra Halad] állapotból átke- 
rül a [Keletre halad) állapotba. 

Az alkalmazás tervezése során fő feladatunk tehát az objektu- 
mok és osztályok egyértelmű azonosítása, feladataik meghatá- 
rozása, és kapcsolataik felderítése. 


Objektumok és osztályok 


Az objektumokról már esett néhány szó, lássuk, mik is azok 
az osztályok, amelyek szintén elkerülhetetlenek az OO világ- 
ban. 

Képzeljünk el ismét egy autót. Természetes emberi módon 
gondolkodva lássuk, milyen osztályba, kategóriába sorolnánk 
az autót: az autó például egy jármű. Természetesen több jár- 
művet is ismerünk: kerékpár, repülőgép, hajó, stb. Ebben az 
esetben azt mondjuk, hogy a Jármű egy osztály, az autó, ke- 
rékpár stb. ennek a Járműosztálynak a példányai. 
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Hajó : Jármű 


kerekSzam : int - 0 
szín : string - Tengerészkék 














Kerékpár : Jármű 
kerekSzat tz2 
szín : string - Piros 


Repülőgép : Jármű 
kerekSzam : int z 8 
szín : string - Fehi 


a A vJárműosztály és példányai 





Mint az emberi gondolkodásban is, az OO programozásban is 
minden objektum jól meghatározott osztályba sorolható már 
a létrejöttekor. 

Természetes módon adódik a kérdés: egy objektumot sorolha- 
tunk-e egyszerre több osztályba is? Mondhatjuk-e például azt, 
hogy a kerékpár egyszerre jármű és sporteszköz? Ezáltal ter- 
mészetesen szeretnénk, ha mindkét osztály tulajdonságait, jel- 
lemzőit magában hordozhatná a programunkban is éppúgy, 
mint a valóságban. 

Ez a megközelítés azonban igen sok problémát felvet: mi tör- 
ténjen akkor, ha a két osztálynak vannak azonos adatai vagy 
metódusai? Hogyan döntjük el, hogy mikor melyiket alkal- 
mazzuk? A kerékpár honnan tudja, hogy őt most sportolásra 
vagy belvárosi közlekedésre használják? 


Ezen megfontolások alapján az objektumorientált program- 
nyelvek többsége nem engedi a többszörös öröklődést, azaz 
minden objektumot egyetlen osztályba sorolhatunk, és min- 
den osztály egyetlen másik osztályból származhat. 
Származhat? Vajon mit jelent ez? Mint már említettem, nem 
elég az objektumok és osztályok azonosítása, ezek kapcsola- 
tait is fel kell térképeznünk a tervezés folyamán. Az osztályok 
közötti kapcsolat egyik típusa az öröklődés, ami a következőt 
jelenti: Adott két osztály, nevezzük az egyiket A-nak, a mási- 
kat B-nek. Akkor mondjuk, hogy A őse B-nek (illetve B az A- 
ból származik), ha közöttük szülő-gyermek viszony áll fenn, 
azaz a gyermekosztály örökli a szülőosztály minden attribútu- 
mát és metódusát. Ezek a származtatott osztályban felülírha- 
tók, és újabb tagokkal egészíthetők ki. 

Például előfordulhat, hogy nem elég egy Járműosztályt defi- 
niálnunk, szükség van arra, hogy újabb osztályokat vezessünk 
be a vízi-, légi- és szárazföldi járművek megkülönböztetésére. 
Ekkor a struktúradiagram így nézhet ki: 





mint 
string 


:t(Emelkedik(in szög : Magasságszög) 
jeHalad(in magasság : int, in sebesség : int) : 3Dirány 


Autó : Szárazföldi 


kerekSzam : int - 0 
szín : string - Tengerészkék 
maxSebesség : long - 50 
maxMagasság : int - 25000 


meghajtás : HajóTípus 





a A járművek statikus struktúradiagramja több járműosz- 
tály esetén 


Jól látható, hogy például a Légi típusú Repülőgépnek tovább- 
ra is megvannak azok az attribútumai, amelyek a Járműosz- 
tályhoz tartoznak, de van egy újabb, maxMagasság attribútu- 
ma is, amely a légi járművek sajátossága. Hasonlóan definiál- 
hatunk saját, az ősosztályhoz nem tartozó attribútumokat a 
többi osztály esetén is. Az is igaz továbbá, hogy a metódusok 
hasonlóan viselkednek: a fenti ábrán nem látható ugyan, de a 
Repülőgép a Halad, Kanyarodik és Fékez tevékenységeken kí- 
vül újabb, Emelkedik metódussal is rendelkezik. 

A Légi osztályban ezen kívül felüldefiniáltuk a haladást: egy 
repülőgépnél nem elég a síkbeli irányt megmondani, mint pél- 
dául az autóknál, háromdimenziós adatra van szükség, hiszen 
emelkedhet illetve süllyedhet is. Ezért a Halad metódus nem 
Irány, hanem 3Dirány típusú lesz, és paraméterezése is más- 
képp alakul, mint az ősosztályban. 


Fontos még bevezetni az absztrakt osztály fogalmát is. A fenti 
modellben elképzelhető olyan eset, amikor egy objektum 


közvetlenül a Jármű osztályból származik, s nem so- ) 
roljuk egyetlen al-osztályba sem: fúj) 


[. —— VÍRUS 
-meghajtás : HajóTípusi 





2 Közvetlenül az alaposztályból származó objektum 
(Roller) 


Ez a megoldás helyenként szükséges és célravezető lehet, 
azonban sok esetben hátulütői is lehetnek: ha nem határozzuk 
meg közelebbről a Roller osztályát, és ezáltal típusát is, nem 
rendelkezünk konkrét, lényegre törő adatokkal és metódusok- 
kal kezeléséhez. A Rollerről például csak annyit tudunk, hogy 
egy jármű, de nem tudjuk, hogy szárazföldi, vízi vagy légi-e, 
esetleg egy negyedik, eddig meg nem határozott osztályba so- 
rolható (pl. földalatti). 

A másik tipikus igény az, hogy szeretnénk olyan osztályokat 
létrehozni, amelyekben definiáljuk, hogy leszármazottaiknak 
milyen attribútumokat és eljárásokat kell megvalósítaniuk, 
azonban ezeket nem feltétlenül konkretizáljuk az ősosztály 
szintjén, a metódusok törzse üres is maradhat. Ez olyankor le- 
het hasznos, ha például azt tudjuk, hogy minden Jármű halad 
valahogyan, de egészen biztosan tudjuk, hogy ezt másképp 
teszi egy repülőgép és másképp egy evezős csónak. Szeret- 
nénk továbbá azt is, hogy ezen osztályon keresztül tudjunk hi- 
vatkozni az alosztályok példányaira is, azaz ha létrehozunk 
vízi és légi járműveket, azok elérhetők legyenek a Jármű osz- 
tályon keresztül is. 

Ezekre a problémákra jelent megoldást az absztrakt osztály. 
Ezek az osztályok nem példányosíthatók, azaz ha a Járműosz- 
tály absztrakt, a fenti Rollerobjektum nem hozható létre köz- 
vetlenül belőle. 


Lássunk egy példát erre is! 

Vonatkoztassunk el most a járművektől, és evezzünk más te- 
rületekre! Tegyük fel, hogy egy szakácskönyvet szeretnénk 
modellezni. Ebben a szakácskönyvben ételrecepteket táro- 
lunk, a különféle koktéloktól, tablettás boroktól és paradi- 
csomlevektől eltekintünk. Az ételek mindegyikére jellemző, 
hogy valamilyen módon készíteni kell, ehhez bizonyos időre 
van szükség, és van kalóriatartalma. Vannak azonban külön- 
böző típusai is az ételeknek: hidegtálak, készételek, sültek, sü- 
temények, stb., és esetenként ezek az osztályok is tovább fi- 
nomíthatók. 

Ahhoz ragaszkodunk, hogy minden egyes étel a lehető legszű- 
kebb osztályba tartozzon, így az Étel alaposztály absztrakt 
lesz: így egyrészt nem tudjuk példányosítani, másrészt rögzít- 
hetjük benne a szükséges metódusokat. Lássuk tehát, hogyan 
néz ki a struktúradiagramunk: 
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elkészítésildő : time 
kalória : int 


sElkészít() 
arTálal() 
ZA ZA 



















asütésildő : time 


aelkészítésiNehézség : int 
aPihentet(in idő : time) 


aElkészít() 


B Az ételreceptek statikus struktúradiagramja 


Az Ételosztály tehát absztrakt, ezt jelöli nevének dőlt betűs 
írása. Ebből származnak a különböző ételosztályok, s a Süte- 
mény osztálynak további leszármazottai vannak. Jól látható, 
hogy az Elkészít() metódus minden leszármazott osztályban 
implementálva van, ezen kívül, ahol szükséges, újabb metó- 
dusok jelennek meg. 

Vegyünk fel egy objektumot, amely például egy Dobostortát 
modellez: 


Dobostorta : Torta 


elkészítésildő : time - 3h 30min 
kalória : int z 1210 
sütésíldő : time z 45min 
elkészítésiNehézség : int - 3 
krém : string - karamell 
alak : tortaAlak - 0 





E A Dobostorta objektum 


Jól látható, hogy az objektum nemcsak a közvetlen ősének 
(szülőjének) attribútumaival rendelkezik, hanem az összes ős 
attribútumaival is. Ez ugyanígy igaz a metódusokra is: nem- 
csak a Torta osztály metódusai hívhatók meg rajta (Díszít és 
Elkészít), hanem a Sütemény osztály Pihentetése és az Étel 
alaposztály Tálalása is. 

Ha legeneráljuk a megfelelő kódokat, és létrehozunk egy do- 
bostortát, amely a Torta osztály egy példánya, a következőt 
láthatjuk: 


Torta dobosTorta - new Tortaí(); 
dobosTorta. 










"ak Díszít 
"249 Elkészít 

4 elkészítésildő 

(4 elkészítésiNehézség 
"Xg Eguals 

"269 GetHashCode 

gy GetType 

4 kalória 

4 krém 


E A dobostorta attribútumai és metódusai 


Vagyis valóban láthatjuk az összes ősosztály valamennyi pub- 
likus tagváltozóját és metódusát. 


Egységbezárás 

A fenti megoldás nagyon szép és nagyon jó, de... Ugye sok- 
szor találkozunk ezzel a mondatszerkezettel? Most is ez kö- 
vetkezik. 

A szakácskönyvben mindent publikussá tettünk, azaz minden- 
ki mindenhez hozzáfér. Azonban mi magunk sem szeretnénk, 
ha minden adatunk a hátunkra lenne írva, hogy az utcán sé- 
tálva bárki láthassa életünk minden egyes apró részletét. Sze- 
retnénk, ha lehetnének privát, személyes dolgaink, és olyanok 
is, amelyeket csak bizonyos személyekkel (objektumokkal) 
osztunk meg. 

Ezért lehetőség van arra, hogy a változókat illetve metóduso- 
kat ne public láthatósággal adjunk meg, mint ahogy azt a fen- 
tiekben tettük. A private kulcsszóval definiált változók és függ- 
vények teljes mértékben elzártak lesznek, azaz az adott osztá- 
lyon kívül senki nem férhet hozzájuk. Az ilyen típusú változók 
csak az osztályon belül érhetők el, a metódusok pedig csak ott 
hívhatók. 

Mindez arra jó, hogy az osztályok között jól körvonalazott in- 
terfészeket definiálhassunk, hogy kizárólag ezeken keresztül 
férhessenek egymáshoz. Így elérhető, hogy transzparens mó- 
don változtathassuk egy osztály belső szerkezetét anélkül, 
hogy kifelé ebből bármi észrevehető lenne. 

Például ha a fenti példában a kalória ábrázolására nem int tí- 
pusú változót definiálnánk, hanem bevezetnénk egy saját tí- 
pust, amely a KJ és Kcal értékeket egyaránt tartalmazó rekord 
lenne, bajban lennénk, hiszen az összes ételt át kellene írni a 
megfelelő új típusokkal. 

Ezzel szemben ha a Kalória attribútum rejtett (private), kívül- 
ről nem férhetünk hozzá, nem is látható. Ehelyett hozzuk lét- 
re a GetCal és SetCal nevű publikus metódusokat, a követke- 
ző megfontolásokkal: eddig a KJ értékeket tároltuk el, most ve- 
zettük be a Kcal-t. A kettő közötti átjárás úgy történik, hogy a 
Kcal értéket 4.18-cal kell megszorozni ahhoz, hogy a KJ érté- 
ket megkapjuk. Ha az int típusú Kalória változónk rejtett volt, 
és a Get/Set párral értük el, akkor ezek megvalósítása így né- 
zett ki: 


public abstract class Étel 


t 1 
private time elkészítésildő; 
private int kalória; 
public virtual void Elkészít() 

( 

EESÉ 

) 





A GetCal metódus tehát a Kalória egész értékét adja vissza, a 
SetCal bemeneti paramétere pedig a beállítandó KJ érték, 
amelyet egyszerűen hozzárendelünk a Kalóriához. 

Ha a struktúrát kibővítjük a Kcal értékek bevezetésével is, kó- 
dunk a következőképp fog kinézni: 





tech.net WoW TK FT ag w i 


A SetCal tehát ugyanúgy KJ értéket kap paraméter- 
ként, s beállítja mind a K]J, mind a Kcal értékeket. 
Egyedül annyi a különbség az előző megoldáshoz 
képest, hogy a GetCal nem int, hanem CalType típu- 
sú értéket ad vissza. Ez sajnos azt jelenti, hogy az 
osztály interfésze megváltozott, kívülről már nem transzpa- 
rens a belső módosítás. 

Ez az a pont, amiért e korai terveket jól és alaposan kell elké- 
szíteni. A fenti kalória egy tipikus olyan példa, amikor a terve- 
zés kezdeti szakaszában nem gondoltuk végig, hogy a válto- 
zónak milyen típusúnak kell lennie, illetve milyen bővítések- 
re lehet igény a felhasználó oldaláról. 

Másik tipikus, ehhez hasonló példa a pénzértékek tárolása. El- 
ső megközelítésben gyakran int vagy long típusú változókat 
hozunk létre, majd a fejlesztés egy későbbi szakaszában 
(rosszabb esetben éles használat közben) jön rá a felhasználó, 
hogy jó lenne többféle valutanemet is lekezelni, és egyébként 
sem egyértelmű, hogy az a 25.000.000 érték forintban vagy 
svájci frankban értendő. Ekkor létrehozunk egy Money osz- 
tályt, ahol a valutanemet és az összeget egyaránt tárolni tud- 
juk, és máris megváltozott az osztály interfésze. . . 


Alig írtam néhány oldalt, s máris mennyi probléma merült fel. 
Az esetek többségében a szoftverfejlesztők és —tervezők mind 
szembesülnek ezekkel a problémákkal: sajnos sokszor saját 
bőrükön tapasztalják, milyen jó lett volna gondosabban ter- 
vezni. A következő hónapokban néhány ilyen buktatót (és 
megoldást) szeretnék bemutatni, amelyeken vagy már túles- 
tem jómagam, vagy láttam a negatív példát, és szeretnék tőle 
megkímélni mindenkit, ha lehetséges. 

Sor kerül tehát a bevezetőben említett valamennyi rövidítés 
értelmezésére, magyarázatára. Aki pedig nem tudja, mi az a 
HBR, járjon utána 


Molnár Ágnes 
aghyEvipmail.hu 
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MCSE (rendszermérnök) képzés MCSA (adminisztrátor) képzés 
az öt kötelező vizsgához a kötelező vizsgákhoz 
430.000 nelyett már nettó 399.000 Ft-tól!!! 270.000 Ft helyett már nettó 229.000 Ft-tól! 
Nagy, összetett informatikai rendszereket és hálóza- A kisebb informatikai rendszereket és hálózatokat 
tokat üzemeltető szakemberek képzése, akiknek fela- üzemeltető szakemberek számára ajánljuk, akiknek 
datuk lesz Windows 2000 alapú hálózatok teljeskörű feladatuk lesz Windows 2000 alapú hálózatok telepí- 
adminisztrálása és támogatása, informatikai infra- tése, konfigurálása, adminisztrálása, karbantartása. 
struktúrák tervezése. 
Szeptember 15-től! Szeptember 15-től! 


A képzéseken a Windows Server 2003-as rendszerek újdonságairól is szó esik. 
Igény esetén a sorozat után kedvezményes Windows Server 2003 átképzést is igénybe vehet! 


MCDBA (adatbázis-adminisztrátor) képzés Microsoft .NET fejlesztői képzés 


a kötelező vizsgákhoz 774.O00 Ft helyett nettó 619.000 Ft-ért! 


Áá Óó tól! 
SO80OGKEhelyett márnettó toszogot estel Fejlesztők, programozók számára ajánlott képzés, 


Microsoft SOL 2000 alapú adatbázisrendszerek tel- akiknek feladatuk lesz összetett, Windows-alapú és 
jeskörű üzemeltetésével, támogatásával, karbantar- webes alkalmazások készítése, fejlesztése, szolgálta- 
tásával, tervezésével és implementálásával megbí- tások implementálása és tervezése. Az alapoktól a 
zott szakemberek részére ajánlott képzés. haladó szintig, párhuzamosan a Ctt és Visual 
Basic .NET programnyelveken. 4 
Szeptember 15-től! Október 13-tól! 


Válassza ki az Önnek megfelelő minősítést és képzési konstrukciót! 





Hivatalos Microsoft tanfolyamokra épülő, rugalmas beosztású, kedvezményes konst- 
rukciójú és árú képzéssorozatok. Különböző segédanyagokat, vizsgafelkészítő anya- 
gokat tartalmazó oktatási konstrukciók és csomagok. Kedvezményes lehetősé- 

gek a szabadon választható vizsgára felkészítő tanfolyamokra. 
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